[BuildTools] COIN_HAS_USER_LIBRARY

[Lou Hafer]

BuildToolers,

      I while back, I said I'd extend the link check in COIN_HAS_USER_LIBRARY
so that it would look for a list of function names and declare victory if it
found any one of them. This avoids a problem when performing the link check
for glpk, which changed the way it declares function names starting with
release 4.14.

	I've done this, works fine. Andreas, I'm going to do a bit more
testing. Expect something early next week, most likely. Macro body on request
if anyone wants to critique.

	But ...

	For those of you who've looked at COIN_HAS_USER_LIBRARY (ok, all two
of us  :-) you know that it forces C as the language to perform the link
check. I gave a fair bit of thought to whether (and how) this could be
relaxed, and it's pretty grim. The problem is that the name mangling and the
syntax for a link check program depend on the both the language of the
library and the language of the client program.  Forcing C as the client
language is the best single choice among C++, C, and Fortran, but it will
likely fail if asked to link against a C++ library that has no functions with
extern "C" linkage (how to guess the name mangling, eh?).

	Bottom line is we need nine cases to get it right. The strategic
question is ``Do we care?'' My thought is that it's only a matter of time
before we're confronted with the case of a C++ library with no extern "C"
functions.

	There is an undocumented autoconf macro (AC_LANG_CASE in lang.m4)
that we can use if we want to go this route. Not as inefficient as it
appears, because only the relevant portions of macro bodies would be expanded
into the configure script; the client and library languages are known when
it's generated. The user can use AC_LANG_PUSH/POP around the call to
COIN_HAS_USER_LIBRARY to set the client language.

	We'll need to add new parameters to COIN_HAS_USER_LIBRARY, one to
specify the language of the library and one to specify a prototype
declaration for the function (C++ requires it, and we should have one for C;
my Fortran is too rusty to remember off the top of my head). And my guess is
that we'll quickly run into trouble in some environment if the parameters to
the function call do not match the function prototype. Which implies the user
needs to supply yet more parameters. Which probably leads to madness.

	There's an alternate approach that deserves consideration: Instead of
asking the user to supply a list of function names, ask them to supply a list
of [[prologue],[body]] pairs that would be handed over as parameters to
AC_LANG_PROGRAM. This puts all the responsibility back on the user, but it's
the ultimate in terms of flexibility.  The user can craft program fragments
that perform a realistic check.

	Another option to consider:  Instead of having COIN_HAS_USER_LIBRARY
abort the configuration if some check fails, just have it set a variable and let
the user decide how to deal with it.  Then COIN_HAS_USER_LIBRARY would not need
to accept a list of function names (or lists for other parameters, for that
matter) --- the user could code multiple calls in configure.ac and decide how to
react to success or failure.  We'd have to guard the declaration of the --with
and --enable command line parameters so that they're declared only once.

	Which leads me to this proposal as a way forward:  Augment
COIN_HAS_USER_LIBRARY to accept a list of function names, but don't enhance it
any further.  It will do the job in a large percentage of cases, and we keep
backward compatibility.  Add a new macro, COIN_HAS_USER_LIB_II, that replaces
the [function name] parameter of COIN_HAS_USER_LIBRARY with [prologue] and
[body] parameters, and simply sets a variable for success or failure.  This
would let us handle problematic cases until we or the autoconf folks think of
something better.

						Lou