Boost C++ Libraries: Ticket #12033: Boostdep misses some dependent components

edaskel@… — Tue, 01 Mar 2016 02:45:50 GMT

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

status changed; owner set

Peter Dimov — Tue, 01 Mar 2016 11:28:38 GMT

owner set to Peter Dimov
status new → assigned

Peter Dimov — Tue, 01 Mar 2016 11:56:07 GMT

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@… — Tue, 01 Mar 2016 16:49:37 GMT

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 — Tue, 01 Mar 2016 17:03:45 GMT

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@… — Tue, 01 Mar 2016 17:35:38 GMT

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 — Tue, 01 Mar 2016 17:44:47 GMT

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.

type changed

edaskel@… — Tue, 01 Mar 2016 18:08:39 GMT

type Bugs → Feature Requests

Peter Dimov — Tue, 01 Mar 2016 22:47:56 GMT

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

edaskel@… — Wed, 02 Mar 2016 01:06:29 GMT

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 — Wed, 02 Mar 2016 09:41:58 GMT

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@… — Wed, 02 Mar 2016 22:52:35 GMT

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 — Thu, 03 Mar 2016 09:09:08 GMT

Fixed, I think.

edaskel@… — Thu, 03 Mar 2016 17:42:16 GMT

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 — Thu, 03 Mar 2016 17:46:12 GMT

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