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

[Stefan Vigerske]

Hi,

Matěj Týč wrote:
> On Mon, 2010-05-17 at 10:50 +0200, Stefan Vigerske wrote:
>> Hi,
>>
>>>> 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,
>> No, we do not want to know them.
>> Cgl should pass its compiler flags to higher level projects, so one does
>> not need to change every project that uses Cgl each time a new
>> cutgenerator is added (or something else changes in the flags).
> 
> OK I hope that I understand that you would like to make things more
> simpler than remembering all different -I flags that are necessary now.

Yes.

> So I have another suggestion - all projects can store their headers that
> are going to be installed in a separate directory. 
> It would make things very simple from more point of views:
>   - It would be immediately visible what files are going to be installed
>   - All subprojects would have to pass only one -I flag
>
> So it could look like this
> 
> coin-cbc/
>  buildtools/
>  Cbc/
>  ...
>  Clp/
>   inc/
>   doc/
>   ...
>   src/
>    includes/
>     coin/
>      public_include_one.h     
>      public_include_two.h
>    some_clp_source.cpp
>    some_clp_header.hpp
>    ...
> 
> The Makefile.am could contain something like
> AM_CPPFLAGS += -I includes
> 
> and the source files would contain
> #include "coin/public_include_two.h"
> 
> And the Cbc project's Makefile.am would contain
> AM_CPPFLAGS += -I $(CLPOBJDIR)/src/includes

But I don't think that one can convince all (CoinAll related) project
managers to change their directory structure, I mean to tell them where
they have to store header files.
I could more imagine that a project stores their include paths somewhere
where another projects configure can find it. Currently we use the
xxx-uninstalled.pc files for this.
Then the fallback for the case that pkg-config is not there parses the
xxx-uninstalled.pc for the compiler flags.
Problem are hidden dependencies here again. If XXX depends on YYY, and
YYY depends on ZZZ, then XXX may find the flags to use YYY from the
yyy-uninstalled.pc file, but it may also require the compiler flags from
ZZZ. That makes the configure.ac files a bit messy for the fallback
currently.

>>> it should be OK. We can't use libtool here, but
>>> pkg-config would not help us anyway.
>> It does, I can just ask pkg-config about the compiler flags for a package.
> 
> I meant it like that if a package is not installed, it is troublesome to
> locate its .pc file.

Since we know the base directory of the subproject and we assume that
the xxx-uninstalled.pc file is in this directory, it's not so difficult
to locate.

> Moreover a "standard" .pc file is usually processed by the configure
> script and relates to the state after installation.
> Having a hand written .pc file for the "subproject build" does not sound
> bad, though.
> Am I right that this is that what you have meant?

Yes, this is what we do. :-)
Btw, there is a kind of small documentation of the pkg-config setup at
https://projects.coin-or.org/CoinTLC/wiki/BuildSystemUsingPkgConfig

I think that gnulib has some interesting features that are missing in
the pkg-config setup. The main hurdle from my point of view is that the
.la files do not communicate header paths.
I agree that this may be ok for building against installed projects
where the directories of the headers can be deducted from the library
paths. But for building against an uninstalled project, something is
missing.
I don't know, maybe one should abandon the idea of building against
uninstalled projects, at least with gnulib? The long term goal is to get
rid of this anyway, if I remember correctly.

Stefan