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 15:07:33

On Wed, Dec 3, 2014 at 2:36 PM, Peter Dimov <lists_at_[hidden]> wrote:
> Andrey Semashev wrote:
>>
>> On Wednesday 03 December 2014 12:55:35 Peter Dimov wrote:
>>
>> > This mechanism kind of already exists,
>> >
>> > #if 0
>> > #include "hidden-dependency"
>> > #endif
>> >
>> > but not all files have been annotated.
>>
>> Yes, but that's quite ugly and error prone. In case of MPL this would mean
>> to add all headers under boost/mpl/aux_/preprocessed (517 files) to
>> boost/mpl/aux_/include_preprocessed.hpp or other headers that use
>> include_preprocessed.hpp.
>
>
> It's not quite that bad. You need a section with 11 includes:
>
> #if 0
> // inform boost.build of hidden dependencies
> # include "boost/mpl/aux_/preprocessed/bcc/_all_.hpp"
> # include "boost/mpl/aux_/preprocessed/bcc_pre90/_all_.hpp"
> ...
> #endif
>
> and 11 copies of the same _all_.hpp header that consists of 47 includes and
> will never change.

I still don't like the idea that we have to mangle the code to guide
the build system. And I don't want to set a precedent in MPL as I know
there are many more places where preprocessor is used to include
headers.

> Ugly and error prone? No more than what's already there, I'd say.

It may not be as error prone for MPL, given that it is basically not
developed nowdays. But the approach is still flawed - you have to
remember to modify unrelated headers in disabled sections when you add
a feature or specialized code branch.

IMHO, either Boost.Build has to parse the code properly, or it should
be guided by its own config files, i.e. Jamfiles. Or it could just
always link all headers.