[BuildTools] [Coin-tlc] Help with build system

[Stefan Vigerske]

Hi,

>> If so, then here is my understanding of the pros&cons of using gnulib
>> instead of pkg-config:
>> [...]
>> - requires usage of libtool to create .la files? (e.g., ThirdParty/ASL
>> does not do that) [or one can create an .la file by hand?]
> 
> My idea was to use gnulib's stuff when configuring a Coin project with
> other Coin projects. We use libtool and we know best how to link with
> our libraries :-)

It would be good not to have to distinguish between Coin projects and
non-Coin projects. Distinguishing between projects that create .la
files, projects that create .pc files, and projects that create neither
of them seems more appropriate to me.

> Concerning other packages, I would keep pkg-config with a check followed
> by gnulib-like approach if the first attempt fails.
> 
> As a side note, gnulib can't process the output of pkg-config, but a
> small wrapper around AC_LINK_IFELSE will do the thing. Don't bother to
> write it, I already have it, I just have to polish it a little bit.
> 
> When not to use pkg-config with external packages?
> What I can think of:
> 	- The user explicitly specifies a library prefix

We usually have the options that a user specifies the linker and
compiler flags of a library to use. I know, this is more or less the
same as you said ;-).

> 	- pkg-config's output is unusable
> In order to be able to do something else than to ask pkg-config, we have
> to support these libraries using gnulib.
> Note that even if a library doesn't use libtool or when it produces
> wrong .la files (like COIN projects do ATM :-), it can be checked using
> gnulib. For instance, here is a macro checking for CBC:
> 
> AC_LIB_HAVE_LINKFLAGS([Cbc], [CbcSolver Cgl OsiClp OsiCbc Osi Clp
> CoinUtils], 
> 		      [ #include <coin/CbcModel.hpp>
> 		        #include <coin/OsiClpSolverInterface.hpp> ], 
> 		      [ OsiClpSolverInterface solver1;
> 		        solver1.readMps("somwhere", NULL);] )

Does one need to specify [CbcSolver Cgl OsiClp OsiCbc Osi Clp
CoinUtils]? In the gnulib manual it says, that this macro searches for
libCbc "and the libraries corresponding to explicit and implicit
dependencies". So shouldn't it be able to recognize the dependency of
Cbc on Cgl, Osi*, Clp, and CoinUtils from the information in the .la files?
I.e., whould the following also be sufficient?
AC_LIB_HAVE_LINKFLAGS([CbcSolver], [],
 		      [ #include <coin/CbcModel.hpp>
 		        #include <coin/OsiClpSolverInterface.hpp> ],
 		      [ OsiClpSolverInterface solver1;
 		        solver1.readMps("somwhere", NULL);] )
(where I assume that CbcSolver has Cbc as dependency (at least, it should))
(btw, solver1.readMps("somwhere", NULL) is only a good test if you can
really ensure that "somewhere" is available)

>> - a not yet build version of project is not found because the .la file
>> is created at build time, not at configure time (e.g., the old-way of
>> configuring and then building a series of projects will not work?)
>> - linking against uninstalled versions of a project is more difficult,
>> since a dependent project cannot communicate compiler flags to a higher
>> level project
> 
> I like your "fat tarballs" that contain everything that user needs in
> order to run the stuff and I would like to keep it.
> You surely share the opinion that it is a good thing to be able to
> quickly install stuff without hunting dependencies in a case when you
> use a small distro.
> 
> (uninstalled = not-yet-installed)

Ah yes, sorry... :-)

> I have tried it with .la files and it works.
> Here is the workflow:
> ----- configure.ac -----
> 1. Check whether we can use system library
> 2. If not, set an according automake conditional and
> 3. use the AC_CONFIG_SUBDIRS([our_subdir]) macro
> ----- root Makefile.am -----
> 4. If a particular AM conditional is set to true, add our_subdir to
> SUBDIRS
> ----- compile dir Makefile.am -----
> 4. If a particular AM conditional is set to true,
> add ../our_subdir/<compile dir>/libsomelib.la to the corresponding
> LIBADD variable.
> I have a minimal example nicely working, so this one is OK.

My point was on projects that use non-standard locations of header files
as long as they are not installed.
E.g., if one downloads Cbc with all its dependencies, then one first
configures all projects, then calls make for all projects, and finally
calls make install.
Thus, when <basedir>/Cbc ist build, it need to access the Cgl header
files located in <basedir>/Cgl/src/CglAllDifferent,
<basedir>/Cgl/src/CglClique, ...
How does Cbc get the information about which -I flags to use if gnulib
is used?
Even worse for Bonmin, which does not even need to know that it depends
on Cgl, but may require the Cgl headers at build time.

I agree that if projects gets installed, then it can put all its header
files in some standard location, and there is no real issue anymore on
how to find out the correct -I flags.
However, I think the requirement is to keep the "old system" where one
can first build all projects and then install them working.

>> - no way to communicate paths of project data (e.g., share/coin/Data/Sample)
> 
> That's right, but if you are OK with the fact that you put the project
> data to $prefix/share/coin/Data/..., you will be all right.

Na ok... that point was mostly there to have at least a few '-'-points
compares to the many '+'-points ;-).

Stefan