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

Subject: [boost] Link dependencies (was: [mpl] [build] [testing] Merge pull requests)
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2014-12-03 03:33:25

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_HEADER)

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.

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?

-- 
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com