Boost logo

Boost :

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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at