Re: [Boost-build] generator problems

Subject: Re: [Boost-build] generator problems
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-03-22 02:13:10

AMDG

On 03/21/2012 08:49 PM, George Georgiev wrote:
> <snip>
> 
> The generated header files repeat the dependencies from the compil
> files, or in our case this will mean that b.h will have #include
> "a.h". And this is where the current generator fails. It does not
> track the fact that b.cpp includes  a.h indirectly because b.h
> includes a.h. This results in the jam build to execute the b.cpp
> compilation before a.compil to be (re)generated. This results in
> compilation error or b.cpp build against outdated a.h depending on is
> the build is initial or incremental.
> 
> To make the case even more complex the compil files could have
> circular dependencies.
> 
> 
> I tried another build systems and they are unable to handle well the
> complexity of my case. It looks like Boost Build has the potential to
> do it, but it seems that it requires some time to be spend with it
> before to be able to develop for it. If some of the more expirenced
> guys in the group is willing to help me with this I can send you the
> project on you personal email - it is 123MB compressed.
> 

That's a bit much for email.  I'm attaching
a version that tries to capture the key
elements of your problem.  (To run this
generator/compil must be in BOOST_BUILD_PATH).

The problem is that <implicit-dependency> is
required when files in one main target include
headers generated by another main target.
(This is unfortunately an unavoidable
consequence of Boost.Build's target model)
What you'd like is for everything to have an
<implicit-dependency> on everything else.
Ideally, you'd like to write

project : requirements <implicit-dependency>$(all-libs) ;

Unfortunately, this create circular dependencies
that Boost.Build can't resolve.  The trick to
solving this is to split up compilation into
separate steps:

for local f in $(files)
{
    cpp $(f).cpp : $(f).compil ;
    obj $(f).o : $(f).cpp : <implicit-dependency>$(files).cpp <pch>off ;
}

Now, all the object files can find all the
headers, and the #include scanner takes
care of the rest.  This is a bit of a pain,
but I don't think it's possible to do better.
I did test this and it seems to work. Running,
  b2 link=static lib1
works correctly.  Note that lib1-1.compil
imports lib2-2.compil, so lib2-2.cpp is
built.  lib2-1.compil is not referred to
by lib1, so lib2-1.cpp is not built.

In Christ,
Steven Watanabe