Re: [boost] Link dependencies (was: [mpl] [build] [testing] Merge pull requests)

Subject: Re: [boost] Link dependencies (was: [mpl] [build] [testing] Merge pull requests)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-12-03 03:53:37

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_at_[hidden]: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.