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?