On Wednesday 03 December 2014 11:33:25 Vladimir Prus wrote:
On 11/12/2014 05:16 PM, Andrey Semashev wrote:
1. Checkout libs/mpl from my fork https://github.com/lastique/mpl/tree/modularization. This is how MPL
looked before it was reverted. You can do it like this: cd libs/mpl git remote add lastiquegit@github.com:Lastique/mpl.git git fetch lastique git checkout modularization cd ../..
At this point you should see modularized MPL - there will be libs/mpl/core directory.
2. rm -f bin* boost 3. cd tools/regression/build 4. b2 -q 5. Notice that this directory is missing: boost/mpl/aux_/preprocessed. You will also notice that a lot of boost/ content is missing.
Andrey,
the error I get is:
../../../boost/mpl/aux_/include_preprocessed.hpp:37:90: fatal error: boost/mpl/aux_/preprocessed/gcc/or.hpp: No such file or directory
The immediate reason it happens is that the inclusion of or.hpp is indirect, via include_preprocessed.hpp:
# define AUX778076_PREPROCESSED_HEADER \ BOOST_MPL_CFG_COMPILER_DIR/BOOST_MPL_PREPROCESSED_HEADER \ # include BOOST_PP_STRINGIZE(boost/mpl/aux_/preprocessed/AUX778076_PREPROCESSED_HEADE R)
Boost.Build cannot see that dependency so it does not know what gcc/or.hpp has to be linked prior to building this source.
It's working in current devel tree, because MPL is handled by a single link action:building reports this:
mklink-or-dir ../../../boost/mpl
So boost/mpl is just a symlink to original location, and it's created very early due to other, discovered, dependencies on MPL. After your modularization, you have headers to two different components. But, you want all headers to be present in boost/mpl, so the only way to accomplish that is to link headers one-by-one, and track header dependencies one-by-one, and it fails due to preprocessor usage.
Yes, I suspected that was the reason.
I see a few possible options:
- Modularize MPL all the way, so that the sub-components are disjoint in install tree, not just in source tree - Add a mechanism to explicitly describe header dependencies that cannot be found - Unconditionally link MPL headers prior to any build
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. 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. 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. PS: Thank you for looking into this.