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

[Matěj Týč]

Thank you for your replies, 
I have CCd the reply to Stefan and Lou to buildtools list, too.

On Mon, 2010-05-10 at 16:25 +0200, Stefan Vigerske wrote: 
> Hi,
> 
> first a few questions to see if I understood correctly:
> - The gnulib macros will get the linker flags and dependencies of a
> library from the library.la file, but the include paths are assumed to
> be some standard locations (e.g., some_directory/include, if the project
> lib is in some_directory/lib)?
> - The gnulib macros are only required at the time the autotools are run,
> but at the time when the project gets compiled, everything is shell
> scripting?
> 
> If so, then here is my understanding of the pros&cons of using gnulib
> instead of pkg-config (apart from throwing away uncountable many
> weekends of work ;-)):
> 
> + easier way to install several versions of a library in parallel (e.g.,
> for cross compiling) [in pkg-config, there is only one .pc file]
> 
> + libraries are checked to be usable
> 
> + no mixing of LDFLAGS and LIBS
> 
> + (a bit dubious) support to create .def file automatically (is this
> also working with fortran code?)
> 
> + may be able to distinguish between lib and lib64
> 
> + no need for the user to install 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 :-)
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
	- 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);] )


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

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.

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

> 
> Stefan
> 


> 
> > [ ... gnulib ... ]
> 
>     Interesting.  Actually attempting a link is definitely the most
> reliable
>     approach.  It's not clear to me that gnulib and pkg-config are
> mutually
>     exclusive.  

pkg-config can't be used directly with gnulib since it tells you the
ldflags and cflags and the gnulib macro doesn't accept them.
Output of pkg-config should be checked by a similar (and much simpler)
macro, that would use the pkg-config output.

> 
> The next three sections in the gnulib manual (exported
>     symbol visibility, ld version, MSVC compatibility) also offer
> promising
>     capabilities.
> 
>     Caveats:  When trying to build linux software on Solaris I've
>     encountered serious issues with symbol visibility.  Some of the
>     functionality seems to depend on GCC 4.0 or better.

I don't know the details of using subdirectories, but I am quite sure
that it is possible to get it working without any serious workarounds.
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.


You are right. However if the compiler can't support that feature, it is
not used and everything compiles like it would compile without that
module. Some slight preprocessor magic has to be used, but nothing too
serious :-)


>   Most everything
>     seems to be m4 macros, but we need to check that there's no actual
> code
>     with GPL licensing.
>     
>     All in all, this looks like it's worth following for a bit.
>     
>                                                 Lou

I begun to write this mail yesterday, so I hope there are not any major
inconsistencies there :-)
Regards,
Matej