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

[Matěj Týč]

On Tue, 2010-06-01 at 10:31 +0200, Stefan Vigerske wrote:
> Hi,
> 
> Am 31.05.2010 22:24, schrieb Matěj Týč:
> > Hello,
> > thank you for your reply!
> > On Sat, 2010-05-29 at 13:02 +0200, Stefan Vigerske wrote:
> >> Hi,
> >>
> >> I don't know, the macro you suggest seem to assemble the compiler flags
> >> at the time where configure is setup, but it should be at the time when
> >> configure is executed.
> > 
> > The idea is that you will know the flags at autoreconf time and you may
> > or may not use them at configure time.
> 
> But what if the dependency change? One still needs to rerun the
> autotools for the higher project then. It is better than having to
> adjust the flags by hand and rerun the autotools, though.

You are right, that's a good point. Although this stuff is not likely to
change too often, the fact is that this is a weak point. The m4 way is
not a good way then.
Configure time resolution is the only one left then :-)

> > You can use a similar logic with sourcing shell scripts, but m4sugar has
> > those nice macros that make it easier :-)
> > 
> >> Also there is already a file that contains dependency and compiler flags
> >> information: xxx-uninstalled.pc.
> >>
> >> Why not implement the following?
> >> 1. If pkg-config is available, use it to collect compiler and linker
> >> flags. Here it does not make a difference, if a project has been
> >> installed or not yet.
> > 
> > Well, personally I wouldn't say that there is no difference. As I see
> > it, if a project is installed, it has a .pc file in the "standard"
> > directory, whereas the not-yet-installed project has it in its source
> > tree. So as I see it, you have to invoke pkg-config in a different ways
> > those two times.
> 
> We know where the uninstalled projects are, so their path is added to
> the PKG_CONFIG_PATH. That's all.

OK, that's quite simple and generally painless :-)

> >> 2. If pkg-config is not available, use gnulib to collect compiler and
> >> linker flags of all installed dependencies. Since they are installed,
> >> the compiler flags are in some way easy (-I<installdir>/include).
> > 
> > Yeah.
> > 
> >> 3. If the first two fails (no pkg-config available and dependencies are
> >> not installed yet), try using gnulib to find linker flags in the build
> >> directories of the dependencies and assemble compiler by parsing the
> >> xxx-uninstalled.pc file (as already implemented).
> > 
> > I would say that we don't need to use the .pc file format since we don't
> > need all of its features. I think that a primitive shell script (just
> > two lines of assignments) that would be sourced in a "parent" script
> > would do the job, too.
> 
> But we have the .pc files already. I do not understand why to create
> another file with more or less the same information - only in a slightly
> different format.

I understand that there is a working solution, this is great. I also
don't doubt that this is a valid solution, but I also see that it has
certain cons.
For our "customers", this would mean that they need to have pkg-config
set up and working if they want to use this kind of installation.
Since this is an installation for "poor people", who don't have anything
(= at least in terms of dependencies :-), maybe neither they have
pkg-config, who knows.
And for possible future COIN developers, they might wonder why
pkg-config solution was used here when a shell solution might do the job
as well with relatively less effort.

> > And those macros I have provided probably would handle recursive
> > dependencies too, like when you want to build library A, you need to
> > access include files both from libraries B and C, where C depends only
> > on B, not on A. I don't know how a big issue is this and whether it is
> > not solved, too...
> > However, I think that the future would be to get rid of situations like
> > these anyway.
> 
> Yes, resolving dependencies is not in the fallback that is currently
> implemented. The dependencies are stored in the .pc file, but there is
> no script that resolves them (at configure time). (The idea was not to
> reimplement pkg-config by shell scripts ;-).)
> But yes, building against uninstalled projects is a situation that
> should be avoided in the future anyway, so options 1 or 2 should always
> be working.

Anyway, I couldn't help myself and I have made a demo of a sh
implementation. Don't take me wrong, I don't try to compete with you, I
just like minimalistic approach :-)
http://pastebin.com/raw.php?i=LzGEMwEN
By "getting rid of those situations" I meant situations when a certain
COIN library libA requires libB headers in order to be useful. I think
that such situation occurs now, there was some discussion concerning
this earlier.
See http://list.coin-or.org/pipermail/buildtools/2010-May/000149.html 2.
I believe the main purpose of making config_xxx.h available...

I don't think that all-inclusive tarball is a bad thing, at least not
when COIN is not packaged by one's favourite distribution... It can be
such a big relief for lazy users :-)
Matej