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-03 16:07:22

On Wed, Dec 3, 2014 at 11:30 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
> On Wed, Dec 3, 2014 at 2:07 PM, Andrey Semashev <andrey.semashev_at_[hidden]>
> 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.