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

On Wed, Dec 3, 2014 at 11:30 PM, Rene Rivera wrote:

On Wed, Dec 3, 2014 at 2:07 PM, Andrey Semashev wrote:

...

IMHO, either Boost.Build has to parse the code properly,

Is there a build system out there that correctly handles the extent of MPLs preprocessor driven header inclusion? I'm asking so that we can ascertain how it could be done.

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

...

or it should be guided by its own config files, i.e. Jamfiles.

Don't know what you mean by that. Can you elaborate?

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.

...

Or it could just always link all headers.

It's possible and easy to change the MPL build files to enumerate header dependencies (it can even be done automatically with globs) with the "dependency" feature. Sorry if I haven't followed this discussion.. But can you elaborate what the use cases are?

AFAIU, MPL build files are not involved into the header linking process. Actually, there aren't any build files for MPL, as it's a header-only library. The use case is that when you build tools/regression/build, the build system only links headers that it can infer from #includes. It fails with modularized MPL because some headers in it are included using preprocessor. See the beginning of this thread.