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

[Stefan Vigerske]

Hi,

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

No, point 3 is about the case where there is no pkg-config
(and dependences are not installed yet).

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

But at last we do shell scripting if pkg-config is not there:
https://projects.coin-or.org/BuildTools/browser/trunk/coin.m4#L3898

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

I think something like the script you propose could be integrated into
the fallback macro around, so that it also follows dependencies.
But instead of projects having to creating a new file with INCLUDE_DIRS
and DEPENDENCIES variables, it should just take this information from
the xxx-uninstalled.pc file. I still don't see why to replicate this
information in two files. :-)

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

I agree.
But one may wanna change it such that from the big tarball one does the
whole configure+make+make test+make install for one project after the other.

Stefan