On December 3, 2014 4:07:22 PM EST, Andrey Semashev
On Wed, Dec 3, 2014 at 11:30 PM, Rene Rivera
wrote: On Wed, Dec 3, 2014 at 2:07 PM, Andrey Semashev
wrote: Frankly, I'm not sure any build system even attempts to parse C/C++, let alone do some preprocessing. I must say, I don't know many build systems, though.
None do, to my knowledge.
The way I see it, it would take a little more than a C++ preprocessor to do this. The preprocessor would have to support macro unfolding to obtain the file name. Note that the unfolding can yield different results depending on compiler/platform/etc., and the build system would have to collect all such combinations to get the full list of the possible includes.
Right.
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? ___ Rob (Sent from my portable computation engine)