Boostdep misses some dependent components

[edaskel@…]

In creating a modular boost build for a client I found that boostdep was missing a few smaller libraries when tracing the dependencies. The library msm depends on fusion, which depends on utility, but boostdep does not list "utility" as among the depdencies of msm.

For a test case, try building libs/msm/doc/HTML/examples/SimpleTutorial.cpp using a version of Boost with only the submodules listed as dependencies of msm. It should complain about not finding boost/utility/result_of.hpp

[edaskel@…]

I noticed afterwards that boostdep lists only the first level dependencies of the given module. Perhaps this is by design?

[Peter Dimov]

boostdep msm or boostdep --primary msm lists the primary (direct) dependencies only. boostdep --secondary msm lists the secondary (indirect) dependencies. You can combine these into one as boostdep --primary msm --secondary msm.

There's presently no easy way to just retrieve a list with all dependencies for the purposes of preparing a modular release. boostdep --list-dependencies, which I use for preparing the dependency list that bpm uses, only lists the primary dependencies as well, because bpm install automatically follows the dependency graph.

[edaskel@…]

Thanks for the information. It seems that "secondary" lists some dependencies that are not necessary for me - for example, container, iterator, range and python. Perhaps one of the primary dependencies requires them for a header I don't use. For example, msm requires a library, and that library has some features that use Spirit or Python. However, msm does not use those features... Nevertheless spirit and python are listed as secondary dependencies.

Will "bpm" check out just the primary and (mandatory) secondary dependencies for a given module? I am experiencing a compile failure so I cannot check it out myself... If not, I think this would be a worthwhile feature that would make modular Boost more attractive.

[Peter Dimov]

Thanks for the information. It seems that "secondary" lists some dependencies that are not necessary for me - for example, container, iterator, range and python. Perhaps one of the primary dependencies requires them for a header I don't use.

That's how boostdep works, yes. It tracks dependencies on a coarse module level, and not on a header file level. If you want to just extract the minimal subset required for msm, you can use bcp, which does work on a header level.

When you tell bpm to install msm, and it installs a dependent module M which uses, say, iterator, it also installs iterator because otherwise you'd have a working msm but won't have a working M, and bpm doesn't do such partial installs.

We've done some work to reduce unnecessary dependencies and make subsets leaner, but there remains a lot to be done, and many maintainers don't consider it a priority as Boost is still oriented towards monolithic releases. Sorry. :-)

[edaskel@…]

I understand. Thanks for considering my request.

In order to sell clients on having Boost as a dependency it's helpful to 1) isolate just the libraries they actually need, and 2) treat them as git submodules so they can be versioned independently of the primary codebase. With an approach based on bcp the code itself is incorporated into the client's project, and they must take charge of maintenance and cannot easily incorporate upstream fixes. Therefore I have chosen to semi-manually generate the dependency list, by starting with the "boostdep" output and adding additional libraries identified by compiler errors.

Would it help for me to make a feature request out of this ticket? Is there a more suitable venue? Thanks!

[Peter Dimov]

I could probably extend boostdep with another report that would show a full dependency list formed by following the header graph instead of the module graph, but I'm currently a bit short of time, so I'm not sure when I'd be able to do that.

[Peter Dimov]

OK, please try boostdep --subset msm on the develop branch.

[edaskel@…]

Thanks! I find that compared with my list it is missing the following libraries:

detail integer move

and this library is excess:

predef

[Peter Dimov]

Could you please give me the inclusion chains that cause detail, integer and move to be needed, so that I can try to track that down? (That would of course depend on which Boost it's run, I'm testing it on the develop branch.)

Predef, in boostdep's opinion, is needed because

boost/msm/front/euml/common.hpp -> boost/mpl/string.hpp -> boost/predef/other/endian.h

which looks correct to me.

[edaskel@…]

predef sounds right to me too. I'm probably not using a header that would expose the dependency.

boost/msm/back/state_machine.hpp => boost/function.hpp => boost/function/detail/prologue.hpp => boost/function/function_base.hpp => boost/integer.hpp

boost/msm/back/state_machine.hpp => boost/function.hpp => boost/preprocessor/iteration/detail/iter/forward1.hpp => boost/function/detail/function_iterate.hpp => boost/function/detail/maybe_include.hpp => boost/function/function_template.hpp => boost/move/utility_core.hpp

boost/msm/back/state_machine.hpp => boost/parameter.hpp => boost/parameter/parameters.hpp => boost/detail/is_xxx.hpp

[Peter Dimov]

Fixed, I think.

[edaskel@…]

I agree! It identifies six more libraries than I am using, but still, it is correct :)

This will be a great tool to help library maintainers prune dependencies. Thanks for implementing this.

[anonymous]

Oh, there's just one issue: "msm" is listed as a dependency of "msm"