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

Subject: Re: [boost] Link dependencies (was: [mpl] [build] [testing]Mergepullrequests)
From: Peter Dimov (lists_at_[hidden])
Date: 2014-12-03 17:26:32

Andrey Semashev wrote:
> 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.

Not very many. Boost.Config has some and it already uses the #if 0 technique 
to mark them. There were a few more occurrences, I forget where.

Either way, if you #include via a macro, you mark with #if 0, if you don't 
(which is most people), you don't, and that's that.

> It may not be as error prone for MPL, given that it is basically not 
> developed nowdays.

It's not (just) that MPL is not developed; it's that the per-compiler 
preprocessed headers are (I suppose) generated by a script, and that same 
script can take care of the dependency _all_.hpp header and even the #if 0 
include, if one is so inclined.

(That last one would require one more level of indirection -

#if 0
#include "boost/mpl/aux/preprocessed/_all_.hpp"
#endif

where _all_.hpp is

#include "bcc/_all_.hpp"
#include "bcc_pre90/_all_.hpp
...

)

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

That also means that you modify unrelated files, even more unrelated than 
the header. It's much better if the dependency information is kept in the 
header rather than being a sidecar that you need to remember to keep in 
sync.