[BuildTools] [Coin-tlc] Help with build system [ticket #foo]

[Matěj Týč]

On Wed, 2010-05-12 at 11:04 +0200, Stefan Vigerske wrote: 
> 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.

I would prefer to use .la files anyway. If a project supplies neither of
them, we should report it as an upstream bug, 
The reason why I wanted to use pkg-config first is that .pc files
usually don't contain mistakes. .la files are messed up from time to
time (of course this is an upstream bug, but people usually don't care
so much).

> 
> > Concerning other packages, I would keep pkg-config with a check followed
> > by gnulib-like approach if the first attempt fails.
> > ... 
> 
> ...
> 
> > 	- 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)

At the moment I can't omit the "dependencies" field in the check, since
the .la files that are created now don't contain the information about
dependencies. As soon as they start doing that, it will be as you have
suggested (see ticket #foo)
Concerning the test, it just links the test program, so those functions
are never called. It is good to check whether they are available in that
particular form.
By the way, the reason that the test program does not get executed, too,
is that it would break cross-compilation.

> 
> >> - 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.

Now I got your point. I would solve that by using the automake
conditional from the point 3 of the workflow. Since we know what -I flag
has to be passed, it should be OK. We can't use libtool here, but
pkg-config would not help us anyway. A slightly modified current
approach should be fine.
What concerns this and gnulib integration generally, I propose to change
the directory tree. I will write a separate mail about that, though.

> 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.

Yes, that's a meaningful requirement and I think that its implementation won't change significantly.

> >> - 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 ;-).

You like balance, that's nice :-)

> 
> Stefan
> 

Matej