Subject: Re: [boost] Link dependencies (was: [mpl] [build] [testing] Mergepullrequests)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-12-04 06:07:42
On Thursday 04 December 2014 05:42:13 Rob Stewart wrote:
> On December 3, 2014 4:07:22 PM EST, Andrey Semashev
> >I had something like the following in mind:
> >1. Boost.Build finds an #include in a source file.
> >2. It determines which library this header belongs to.
> >3. It parses the header to obtain the "obvious" dependencies from
> >#includes not obscured by preprocessor.
> >4. It also peeks into the library Jamfiles to obtain dependencies
> >defined by the library developer.
> >1-3 is basically what happens now. 4 is needed to explicitly describe
> >dependencies which Boost.Build is unable to infer from headers. If
> >Jamfiles don't fit for this role, I'm ok if it's a different config
> Why not a dedicated header that exists to guide Boost.Build?
With the current state of things this header would have to be included where
preprocessor magic happens, possibly #if-ed out. It isn't really different
from just placing the #if-ed out #includes instead of the dedicated header.
If Boost.Build is supposed to "know" about this header and parse it
automatically without having to #include it anywhere then why is it a header
and not a config file?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk