On 12/03/2014 11:53 AM, Andrey Semashev wrote:
Comments?
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 <mpl/...> include is found, add dependency on every MPL header".
However, if the description is made on the sublibs level (i.e. that "libs/mpl depends on libs/mpl/core" and that makes all MPL.Core headers linked) this might be ok.
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.
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. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com