Hi all, I have been doing some tests with bcp recently, and the number of files I get for even the smallest header-only libraries (at least on the surface) is quite surprising to me. I know that not all files are used for compilation on a given platform, but I would still like to avoid putting 1253 files (11.7 MB) in my source tree just because I use a tiny part of Boost (boost/unordered_map.hpp in this case). I am wondering, will the effort that I have been reading about to modularize Boost, attempt to reduce some of these interdependencies? Or is the idea more about reducing the download size of the Boost distribution itself? Thanks in advance for any clarification. Kind regards, Philip Bennefall
Hello Philip,
Gesendet: Donnerstag, 17. Oktober 2013 um 23:53 Uhr Von: "Philip Bennefall" <philip@blastbay.com> An: boost@lists.boost.org Betreff: [boost] Extensive interdependencies in Boost
Hi all,
I have been doing some tests with bcp recently, and the number of files I get for even the smallest header-only libraries (at least on the surface) is quite surprising to me. I know that not all files are used for compilation on a given platform, but I would still like to avoid putting 1253 files (11.7 MB) in my source tree just because I use a tiny part of Boost (boost/unordered_map.hpp in this case).
I know what you mean, but have a little different opinion on it. I'm the author of the boost dependency analyzer, which is also bcp based, so I do have some expierence at looking at its results: http://meetingcpp.com/index.php/br/items/releasing-boost-dependency-analyzer... So my opinion on this: First you must understand, that bcp will give you the MAX Dependencies of any lib, this means it will export everything that could be ever used with the lib you have choosen. This can include tests, it includes the inner, normally not directly visible dependencies in boost (config f.e.), and the may-be-you-also-will-want-to-use-this-boost-lib dependencies. For example a library supports handling of shared_ptr, you see this as a dependency in bcp, even if your own code doesn't use shared_ptr. So, what bcp exports is always - as far as I understand - all the dependencies that could exist. So yes, you get the whole package.
I am wondering, will the effort that I have been reading about to modularize Boost, attempt to reduce some of these interdependencies? Or is the idea more about reducing the download size of the Boost distribution itself?
Not involved in this work, so I can't answer it, but same as with bcp I think you run into the problem of not knowing which dependency is actually not needed/used by the user. kind regards, Jens Weller
Thanks, Jens. What you say makes sense. I guess my next question would become, is it perhaps possible to extend bcp to be a little more selective? Since Boost already has a preprocessor implementation, maybe this could be used to follow some macro paths to determine what needs to be included? The user would naturally have to specify some macros that bcp could work with, but this seems to me to be an effective way of making bcp a little more picky when generating its output depending on the user's needs. Another, perhaps less realistic option, would be if bcp could actually analyze what parts of a certain library the user's code calls upon. For instance, if I never use a smart pointer for a given container we would not need that dependency. This, I realize, is far more involved and might not be at all practical to implement. I'm just throwing the suggestion out there for some discussion. Kind regards, Philip Bennefall ----- Original Message ----- From: "Jens Weller" <JensWeller@gmx.de> To: <boost@lists.boost.org> Sent: Friday, October 18, 2013 12:03 AM Subject: Re: [boost] Extensive interdependencies in Boost Hello Philip,
Gesendet: Donnerstag, 17. Oktober 2013 um 23:53 Uhr Von: "Philip Bennefall" <philip@blastbay.com> An: boost@lists.boost.org Betreff: [boost] Extensive interdependencies in Boost
Hi all,
I have been doing some tests with bcp recently, and the number of files I get for even the smallest header-only libraries (at least on the surface) is quite surprising to me. I know that not all files are used for compilation on a given platform, but I would still like to avoid putting 1253 files (11.7 MB) in my source tree just because I use a tiny part of Boost (boost/unordered_map.hpp in this case).
I know what you mean, but have a little different opinion on it. I'm the author of the boost dependency analyzer, which is also bcp based, so I do have some expierence at looking at its results: http://meetingcpp.com/index.php/br/items/releasing-boost-dependency-analyzer... So my opinion on this: First you must understand, that bcp will give you the MAX Dependencies of any lib, this means it will export everything that could be ever used with the lib you have choosen. This can include tests, it includes the inner, normally not directly visible dependencies in boost (config f.e.), and the may-be-you-also-will-want-to-use-this-boost-lib dependencies. For example a library supports handling of shared_ptr, you see this as a dependency in bcp, even if your own code doesn't use shared_ptr. So, what bcp exports is always - as far as I understand - all the dependencies that could exist. So yes, you get the whole package.
I am wondering, will the effort that I have been reading about to modularize Boost, attempt to reduce some of these interdependencies? Or is the idea more about reducing the download size of the Boost distribution itself?
Not involved in this work, so I can't answer it, but same as with bcp I think you run into the problem of not knowing which dependency is actually not needed/used by the user. kind regards, Jens Weller _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/18/2013 12:14 AM, Philip Bennefall wrote:
Thanks, Jens. What you say makes sense. I guess my next question would become, is it perhaps possible to extend bcp to be a little more selective? Since Boost already has a preprocessor implementation, maybe this could be used to follow some macro paths to determine what needs to be included? The user would naturally have to specify some macros that bcp could work with, but this seems to me to be an effective way of making bcp a little more picky when generating its output depending on the user's needs.
Another, perhaps less realistic option, would be if bcp could actually analyze what parts of a certain library the user's code calls upon. For instance, if I never use a smart pointer for a given container we would not need that dependency. This, I realize, is far more involved and might not be at all practical to implement. I'm just throwing the suggestion out there for some discussion.
Hello, I've already done some analysis work on the dependency graph over the last week. See the thread I've just started. I did trace the #include dependencies between repos. Thanks, Steve.
participants (3)
-
Jens Weller -
Philip Bennefall -
Stephen Kelly