On Wednesday 03 December 2014 12:48:18 Vladimir Prus wrote:
On 12/03/2014 11:53 AM, Andrey Semashev wrote:
Such mechanism would require modification to the MPL Jamfile, am I correct? I generally don't like when I have to manually describe dependencies, because when the code is modified these descriptions often get overlooked.
I was thinking more about "Whenever
include is found, add dependency on every MPL header".
Hmm, that means to hardcode MPL somewhere, and this won't scale for other libraries, if we go on modularizing. I'd prefer a more general solution - ideally, totally automagic and transparent, otherwise, if not possible, at the library developers' control.
Why not just run the headers target before building anything. b2 headers does the right thing, and any project inside Boost implicitly relies on the boost/ directory tree. I was trying to accomplish that by modifying the tools/regression/build/Jamroot.jam (see my pull request). My reasoning is that since b2 cannot deduce #includes from headers in cases involving preprocessor, like in MPL, we should not rely on it and just always link all headers. It is an option, yes. It's not entirely perfect because all headers will be linked even if you build a single library.
Well, yes. In the long term, when we support modularized builds this can probably matter, although not necessarily so. I imagine, when Boost gets truly modular, one would download sources of the needed libraries separately, and to build them one would have to link all headers from these libraries anyway. With the current state of affair, I don't think there's a problem to link all Boost headers regardless of the built libraries, at least for testing. I mean, we have to do this anyway in order to test and distribute Boost, and I bet no- one is trying to build Boost themselves from git without running 'b2 headers'. AFAIR, no-one complained about it so far.
By the way, do you know why implicit-dependency on the headers target in that Jamfile does not work? My understanding is that its intention was exactly what I suggested above.
Because the effect of 'implicit-dependency' is:
1. When you see include of a header ... 2. ... check that other target mentioned by implicit-dependency ... 3. ... and it's generating such header ... 4. ... add dependency.
In our cases, preprocessor magic hides the fact that gcc/or.hpp is included, so the process breaks at step 1, and whether we have implicit-dependency or not no longer matters.
I see, thanks. So, in order to resolve the problem with testing, do you think my pull request[1] is valid? It basically changes 'implicit-dependency' to 'dependency', which, I assume, is not conditional on the included headers. [1] https://github.com/boostorg/boost/pull/39