Boost logo

Boost-Build :

Subject: Re: [Boost-build] BUMP: [git] genrating forward headers
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2013-08-03 13:27:59


AMDG

On 08/03/2013 08:07 AM, Bjørn Roald wrote:
> However one build file is a little odd:
> libs/spirit/example/qi/json/build/Jamfile
> so I ignore it for now as it is an example.

That should also be changed to <implicit-dependency>
and moved from the sources to the requirements.

> for my testing I also removed the Jamroot
> explicit headers ;
> line from the patch as it is not needed when we are not checking this into svn.

It should be in the final version, though.
and the stage target should be made to depend
on the headers target.

>
>> - Add <implicit-dependency>/boost//headers to all
>> library and test targets.
>
> Steven, is this to assure we have a complete build graph?
>
> I may misunderstand this, but are you saying we should explicitly declare:
>
> <implicit-dependency>/boost//headers
>
> on *all* targets that depend on *any* of the generated links/copies of
> boost headers?
>

Yes. It could be declared in a Jamfile in libs/ to add
it to all the targets automatically. (Putting it directly
in Jamroot is tricky, since we would need to avoid
creating a cyclic dependency.)

> From a logical point of view I struggle with this. I like the concept
> of calling the dependencies implicit as they are an artifact of the
> layout chosen by the super project and the fact that library headers are
> staged before build.

That's the thing, though. The headers are not a special
pre-build step. They're part of the regular build. If
the dependencies are missing, then there's no guarantee
that they will be built first. In particular, parallel
builds would be liable to fail randomly.

> However this implicit-dependency should not be
> explicitly declared in each project. The individual parts (nodules) of
> boost should just declare their dependency to other libraries (modules).
> The fact that the top level layout choices in boost currently does a
> pre-build stage of the headers in <boost-root>/boost is an artifact the
> individual build files and targets should not be concerned with. They
> should work just as well with alternative top level layouts, say we did
> not stage the headers and just created a -I<boost-root>libs/a/include
> for the command line to each library the current target depended on.
>

It's certainly possible to have dependencies
on individual header targets, but using the
global /boost//headers is by far the easiest
way to make it work.

In Christ,
Steven Watanabe


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk