Re: [boost] Link dependencies (was: [mpl] [build] [testing] Mergepullrequests)

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