bcp: towards a library dependency list
I've just committed some changes to bcp that give it a shortened list option: bcp --list-short truncates the list so you just see directory names where appropriate, for example: bcp --list-short shared_ptr.hpp Gives the dependency list: boost/assert.hpp boost/checked_delete.hpp boost/config.hpp boost/config boost/current_function.hpp boost/detail boost/mpl boost/non_type.hpp boost/preprocessor boost/shared_ptr.hpp boost/static_assert.hpp boost/throw_exception.hpp boost/type.hpp boost/type_traits boost/version.hpp which is reasonably nice and compact :-) Now, here's the question: what did the folks who were asking for this functionality actually want to use the information for? I should stress that it's overkill for extracting subsets of Boost, because many libraries will depend on just one or two files inside boost/mpl or boost/preprocessor, so using the list for that purpose will result in an even "thicker" dependency than copying with bcp already produces. It's possible to contract the above list even further: for example by contracting to library names where possible, so for example contracting all of: boost/regex.hpp boost/regex libs/regex to just "regex" However there would still be a lot of Boost headers that can't automatically be assigned to any library name, so it's not clear to me how much use this would be? If folks can give me an idea of what they were looking to use a dependency list for it'll help me decide whether to stop here or to continue trying to contract the list further. John.
"John Maddock" wrote [...]
Now, here's the question: what did the folks who were asking for this functionality actually want to use the information for?
I didnt ask, but it strikes me that this could be a way towards a more modular boost. Now shared_ptr author can say, "my library (currently?) depends on the following modules: mpl preprocessor. type_traits So grab those modules (with the same distro number) too in order to use it." What messes up the calm paradise are the odds and sods Ideally the odds and sods could be made modular too, so for example config.hpp and version.hpp could go to <boost/config/config.hpp>. detail would simply not exist! static_assert would go in <boost/assertion/static_assert.hpp> or whatever. These could just forward to the odds and sods headers but would be preferred over the orphans. In an ideal World ;-) regards Andy Little
Andy Little wrote:
"John Maddock" wrote
[...]
Now, here's the question: what did the folks who were asking for this functionality actually want to use the information for?
I didnt ask, but it strikes me that this could be a way towards a more modular boost.
Now shared_ptr author can say,
"my library (currently?) depends on the following modules:
mpl preprocessor. type_traits
It doesn't, not in its default configuration. Only quick_allocator depends on type_traits.
"Peter Dimov"
Andy Little wrote:
"my library (currently?) depends on the following modules:
mpl preprocessor. type_traits
It doesn't, not in its default configuration. Only quick_allocator depends on type_traits.
Its technically correct then... only confusing. I consider that reasonable without making the dependency crawler incredibly complicated. For the dependency list to make sense, would require a reorganisation of some of the odds and ends in the current boost tree as I suggested above. shared_ptr would then depend on whatever module quick_allocator was put in. regards Andy Little
It doesn't, not in its default configuration. Only quick_allocator depends on type_traits.
Right, and this is one of the problems with robot-derived dependency lists: they pick up everything, even things that are rairly used (workarounds for old compilers etc). John.
John Maddock wrote:
It doesn't, not in its default configuration. Only quick_allocator depends on type_traits.
Right, and this is one of the problems with robot-derived dependency lists: they pick up everything, even things that are rairly used (workarounds for old compilers etc).
Using Wave to extract the set of used include files (with a well defined set of predefined macros to select the required compiler) would help to overcome this issue, IMHO. Regards Hartmut
Hartmut Kaiser wrote:
John Maddock wrote:
It doesn't, not in its default configuration. Only quick_allocator depends on type_traits. Right, and this is one of the problems with robot-derived dependency lists: they pick up everything, even things that are rairly used (workarounds for old compilers etc).
Using Wave to extract the set of used include files (with a well defined set of predefined macros to select the required compiler) would help to overcome this issue, IMHO.
Also, the user should be able to add possible implementation-defined macros when running bcp under this scenario in order to eliminate parts of an implementation which he will never use from the final set.
On Sat, 11 Feb 2006 13:44:36 -0000, John Maddock wrote
It doesn't, not in its default configuration. Only quick_allocator depends on type_traits.
Right, and this is one of the problems with robot-derived dependency lists: they pick up everything, even things that are rairly used (workarounds for old compilers etc).
I agree with John here -- the automatically derived dependencies are insufficient. For example, date-time includes some serialization headers to make date-time types serializable. However, as long as you never include the date-time serialization headers you don't need serialization. So the dependency is optional based on the features you use. It's not something that's obvious from running an automated tool... Jeff
John Maddock wrote:
I've just committed some changes to bcp that give it a shortened list option:
bcp --list-short
truncates the list so you just see directory names where appropriate
Amazing... :-)
Now, here's the question: what did the folks who were asking for this functionality actually want to use the information for?
We need to generate a dependency graph or some "uses" and "used by" lists for each of the libraries. This information has many uses, e.g. the assessment of likely collateral damage if a library is modified and fails to function. Jim
"John Maddock" wrote:
I've just committed some changes to bcp that give it a shortened list option:
bcp --list-short
[snip]
If folks can give me an idea of what they were looking to use a dependency list for it'll help me decide whether to stop here or to continue trying to contract the list further.
Possibly project management bureauracy. It can get absurd sometimes. /Pavel
participants (8)
-
Andy Little -
Edward Diener -
Hartmut Kaiser -
Jeff Garland -
Jim Douglas -
John Maddock -
Pavel Vozenilek -
Peter Dimov