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

[Matěj Týč]

On Wed, 2010-05-19 at 23:38 +0200, Stefan Vigerske wrote: 
> Hi,
> 
> Matěj Týč wrote:
> > On Mon, 2010-05-17 at 10:50 +0200, Stefan Vigerske wrote:
> >> Hi,
> >>> 
> > 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/
> > ... 
> > 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.

I think that nobody will be able to resist to a smarter solution :-)
Well, I have some other ideas how the directory tree could be
reorganized, so I will post them with the appropriate reasoning and
maybe project managers will like that.
On the other hand, SVN does not handle file moves very well, so there
may be a problem even if the reorganization idea is perfect.
The other possibility that I can think of would be using another
solution than a .pc file.
The benefit of pkg-config is that they provide a standard way of
checking for CFLAGS and LDFLAGS. We need only CPPFLAGS and other
dependencies and we need it only for our purposes, nobody cares whether
we use pkg-config or not there.
So I suggest using a file containing only CPPFLAGS and dependencies.
Then there could be a script (or a m4 macro) that would go through all
dependencies recursively and fetching CPPFLAGS from them.
It could look like this (copy&paste to your shell, all will happen in a
subdirectory):
http://pastebin.com/raw.php?i=rgkBXCL0
Of course the calls of m4_append within cppflags.m4 should be wrapped,
but this should be OK as a demonstration.

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

Yes, you are right, although it means that you have to do things in a
way that users are not used to.
There's nothing fundamentally wrong with it, it just tends to make the
build system more cryptic.

> > 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 have not studied it line by line but, I will do that as soon as I have
more time. 
What comes to my mind when I see that is that it would be nice to stick
to "standard" macros more than creating custom ones if it is possible.
I know that my macro contribution doesn't really show that I am a
supporter of this approach, but at least let's not forget advantages of
simplicity :-)

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

As I say, it would be nice to have it. Imagine that you have a distro
that doesn't have any COIN stuff in their repos. And imagine the pain of
a user trying to compile some of it and therefore having to deal with
all of COIN dependencies... 
I think that the macro that I have provide a good start.

> 
> Stefan

Sorry for my lack of flexibility, but I have been busy above average the
past week, it should settle down a bit now.
Regards,
Matej