Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-09-29 02:06:49

On Thursday 28 September 2006 23:00, Fabien Chêne wrote:
> David Abrahams <dave_at_[hidden]> writes:
> > fabien.chene_at_[hidden] (Fabien Chêne) writes:
> >> I think the documentation is not clear enough about this problematic
> >> limitation (the problem is the same with classic Jam).
> >> Someone to confirm/infirm that ?
> >
> > Confirmed.
> >
> >> If confirmed, is there a workaround ?
> >
> > You can improve the scanner that looks for header files by adding
> > custome regexps to detect your macros
> Yes, i saw the exemple given by Rene Rivera (thanks). but for
> example, when we want to convert a large GNU make based project into a
> Boost.Jam/Build[2] based project, we have to be conscious of the
> existence of such « dependant include ». Otherwise, we can be in big
> troubles :-(

If you want to verify there won't be trouble, as opposed to actually using
this include syntax, I think you can grep all your sources for #include
lines, then grep out lines that are sane, and manually look at the remaining

It might be more straight-forward solution that modifying bjam.

> That's why i would find it comfortable to be warn about such probably
> silent miscompilation -- i don't know how, a line command option for
> [b]jam ?.
> In fact, it is much more simple to find a work-around for « dependant
> include » modifying the C/C++ code than modifying Jam rules.
> The problem is indeed when converting a project that contains
> §16.2.4-include.

Ideal approach might be to generated dependency information using C compiler
itself. I think that gcc's -M -MF whatever set of options can be used to
write dependency information at the same time as compiling; we can read this
output later.

Original Jam avoided this on grounds on not wanting to create extra
bookkeeping files, but I don't think we agree to that desire.

> >> And i would find it more safe to block the build if an include is not
> >> of the form of :
> >
> > That would make it useless for Boost, unfortunately.
> I'm not sure to understand. Did you mean for building Boost libraries ?
> (I don't see such « dependant include » in Boost, maybe i'm wrong)

There are.

- Volodya

Vladimir Prus
Boost.Build V2:

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at