Road to low-quality-code is paved with good intentions of dropping dependencies
Hi all, I've been looking through the latest changes to drop dependencies. Stuff that I saw is very frightening. For example: https://github.com/boostorg/move/blob/develop/include/boost/move/detail/type... . Every boost release some issues are fixed in intrinsics of TypeTraits and is_move_* is_nothrow_* traits. Copy-pasting code from TypeTraits feels like loading a gun and pointing it on own foot. Another example is a sad story of boost::swap. We can not use Boost.Move here because it will add "a lot of dependencies" to Boost.Core. This leads us to nonoptimal implementation, which is sad. The Solution Almost *all* of the Boost libraries depend on TypeTraits, MPL, Core, Assert, StringRef. Language emulation features implemented in Exception, Move, StaticAssert, TypeIndex should be also widely used. hash_fwd.hpp must be used by almost all the containers and structures. So may be we should think of those libraries as of "base" libraries! I do not mean that they must be moved in a single "base" folder. I'm talking only about dependency reports: those libraries must be treated by the dependency tool as a single one and must have the level 1. Those libraries are "base", because they are the very common part of Boost framework. Not using them is more like a bad decision, reimplementing parts of them is an afwull decision. Threating them as base/common/core/main part of Boost seems reasonable. -- Best regards, Antony Polukhin
On 01/07/2015 11:49 AM, Antony Polukhin wrote:
So may be we should think of those libraries as of "base" libraries! I do not mean that they must be moved in a single "base" folder. I'm talking only about dependency reports: those libraries must be treated by the dependency tool as a single one and must have the level 1.
I think that we should have a single person that should resolve these circular dependencies between many base libraries. Without this it will be just a declaration of intent. Regards, Kolya.
Note, not disagreeing, or agreeing, with you. But.. On Wed, Jan 7, 2015 at 3:49 AM, Antony Polukhin <antoshkka@gmail.com> wrote:
So may be we should think of those libraries as of "base" libraries! I do not mean that they must be moved in a single "base" folder. I'm talking only about dependency reports: those libraries must be treated by the dependency tool as a single one and must have the level 1.
You do realize that the report is only showing the node distances of the code dependency graph? No one ordained anything in that report as being any particular level. And what you are suggesting would not result in a dependency report? Those libraries are "base", because they are the very common part of Boost
framework. Not using them is more like a bad decision, reimplementing parts of them is an afwull decision. Threating them as base/common/core/main part of Boost seems reasonable.
Treating them as base, or whatever, is irrelevant to the what is in the report. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
El 07/01/2015 a las 10:49, Antony Polukhin escribió:
Hi all,
I've been looking through the latest changes to drop dependencies. Stuff that I saw is very frightening.
For example: https://github.com/boostorg/move/blob/develop/include/boost/move/detail/type... . Every boost release some issues are fixed in intrinsics of TypeTraits and is_move_* is_nothrow_* traits. Copy-pasting code from TypeTraits feels like loading a gun and pointing it on own foot.
I really don't agree. I've measured the code bloat that TypeTraits and other "low-level" libraries were bringing to some libraries and it was very noticeable. I would like to depend only on TypeTraits but that's impossible, it brings MPL, Preprocessor, etc. Including boost/container/vector.hpp was bringing MB of preprocessed lines, comparing it to 200KB of preprocessed code for <vector> and several users were complaining about compilation times. Compilation times have improved with the dependency removal. I've contributed a little bit to Boost.TypeTraits and I'd like to use it, but only if we can make Boost.TypeTraits depend only on Config/Predef. Currently, in some compilers (like VC7.1 which is the minimum that my libraries support) -> #include <boost/type_traits/aligned_storage.hpp> generates a ~400KB preprocessed file. -> #include <boost/type_traits/has_trivial_destructor.hpp> generates a ~300KB preprocessed file. -> #include <boost/type_traits/has_nothrow_copy.hpp> generates a ~300KB preprocessed file. -> #include <boost/type_traits/is_enum.hpp> generates a ~100KB preprocessed file. -> #include <boost/type_traits/is_pod.hpp> generates a ~300KB preprocessed file. etc... On the other hand, -> #include <boost/move/detail/type_traits.hpp> leads to only ~30KB of preprocessed code, and that includes all the traits Move, Intrusive, Container and Interprocess currently need in the compilers those libraries support. The implementation might not be correct in all corner cases, but it's what those libraries need. My opinion is that nobody should be forced to depend on MPL, Exception, Move, TypeIndex, StringRef etc. Forward declarations can be used whenever possible to avoid header dependencies and tag detection or similar techniques could be used to avoid including parts of other libraries in TypeTraits. Maintaining an intrinsics header it's an additional work but I think it's worth the effort to improve the usability of some libraries. In general, I think that Peter's proposal (http://lists.boost.org/Archives/boost/2014/06/213850.php) to simplify TypeTraits is the way to go, only an internal bool should be enough. But that might break a lot of code, I'm afraid. Note that we still have interoperability problems between std:: and boost:: types (mpl::bool_, boost::integral_constant<bool>, std::true_type...) that don't make current boost approach a definitive answer to libraries that might want to be compatible with std:: traits. boost::integral_constant is not the definitive answer if you want to be nice with some standard utilities. A boost::true_type lying in Core, that can be constructed from anything that has an internal static constant boolean with value true is the key for interoperability between boost, standard or custom traits.
Those libraries are "base", because they are the very common part of Boost framework. Not using them is more like a bad decision, reimplementing parts of them is an afwull decision. Threating them as base/common/core/main part of Boost seems reasonable.
I think the definitive answer is to reduce coupling between those "base" libraries, IMHO those "base" libraries are too heavy now. If we can reduce that coupling, I'd happily switch back to Boost.TypeTraits or just reuse TypeTrait's intrinsics header if that header does not depend on MPL and indirect additional dependencies. Ion
Ion Gaztañaga wrote:
I would like to depend only on TypeTraits but that's impossible, it brings MPL, Preprocessor, etc.
Regardless of what we ultimately do with TypeTraits, I think that a "core type traits" module with minimal dependencies (and no base classes) would be of at least interim value to people like Ion (and myself, for that matter) who would like to use type traits in f.ex. move and smart_ptr, but without the unnecessary dependencies on MPL, Preprocessor, TypeOf and Utility. In fact, Ion may already have started this work, inside his own module. The reasonable way forward, in my opinion, is for us to create a new module for core type traits, with (say) Ion and John Maddock as maintainers, to which then the implementations (and tests) of TypeTraits will gradually migrate. TypeTraits will then use the core traits to derive the trait value, then add all of the compatibility baggage on top for people who like that sort of thing.
The reasonable way forward, in my opinion, is for us to create a new module for core type traits, with (say) Ion and John Maddock as maintainers, to which then the implementations (and tests) of TypeTraits will gradually migrate. TypeTraits will then use the core traits to derive the trait value, then add all of the compatibility baggage on top for people who like that sort of thing.
As already suggested here: http://lists.boost.org/Archives/boost/2014/06/213903.php
On Wed, Jan 7, 2015 at 8:33 AM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
El 07/01/2015 a las 10:49, Antony Polukhin escribió:
Hi all,
I've been looking through the latest changes to drop dependencies. Stuff that I saw is very frightening.
For example:
https://github.com/boostorg/move/blob/develop/include/boost/move/detail/type... . Every boost release some issues are fixed in intrinsics of TypeTraits and is_move_* is_nothrow_* traits. Copy-pasting code from TypeTraits feels like loading a gun and pointing it on own foot.
I really don't agree. I've measured the code bloat that TypeTraits and other "low-level" libraries were bringing to some libraries and it was very noticeable. I would like to depend only on TypeTraits but that's impossible, it brings MPL, Preprocessor, etc. Including boost/container/vector.hpp was bringing MB of preprocessed lines, comparing it to 200KB of preprocessed code for <vector> and several users were complaining about compilation times. Compilation times have improved with the dependency removal. I've contributed a little bit to Boost.TypeTraits and I'd like to use it, but only if we can make Boost.TypeTraits depend only on Config/Predef.
For all the type traits that are now supported by the standard library in use, it might be nice if #include <boost/type_traits/std/some_trait.hpp> brought in the standard library version. So eventually the many boost libraries that use only type traits that have been standardized would have no dependencies on the actual boost implementations. --Beman
On 7 January 2015 at 09:22, Beman Dawes <bdawes@acm.org> wrote:
For all the type traits that are now supported by the standard library in use, it might be nice if #include <boost/type_traits/std/some_trait.hpp> brought in the standard library version. So eventually the many boost libraries that use only type traits that have been standardized would have no dependencies on the actual boost implementations.
In order to do that, we need to somehow unify the following unrelated types: std::integral_constant<bool, b> boost::integral_constant<bool, b> boost::mpl::integral_c<bool, b> Otherwise, it'll break the world, as most usages of type traits are either via tag dispatching or enable_if. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Nevin Liber wrote:
In order to do that, we need to somehow unify the following unrelated types:
std::integral_constant<bool, b> boost::integral_constant<bool, b> boost::mpl::integral_c<bool, b>
Otherwise, it'll break the world, as most usages of type traits are either via tag dispatching or enable_if.
I've already suggested a way to do that. Namely, integral constant types of type T and value v need to acquire a converting constructor from anything of type U for which U::value == v.
Nevin Liber wrote:
In order to do that, we need to somehow unify the following unrelated types:
std::integral_constant<bool, b> boost::integral_constant<bool, b> boost::mpl::integral_c<bool, b>
Otherwise, it'll break the world, as most usages of type traits are either via tag dispatching or enable_if.
I've already suggested a way to do that. Namely, integral constant types of type T and value v need to acquire a converting constructor from anything of type U for which U::value == v.
As explained in http://lists.boost.org/Archives/boost/2014/06/214248.php
In order to do that, we need to somehow unify the following unrelated > types:
std::integral_constant<bool, b> boost::integral_constant<bool, b> boost::mpl::integral_c<bool, b>
Otherwise, it'll break the world, as most usages of type traits are either via tag dispatching or enable_if.
I've already suggested a way to do that. Namely, integral constant types of type T and value v need to acquire a converting constructor from anything of type U for which U::value == v.
As explained in http://lists.boost.org/Archives/boost/2014/06/214248.php
I think these suggestions put the cart before the horse - if only "modern" compilers are to be supported - and most of these techniques seem to require something reasonably modern - then most of the type_traits dependencies could be removed anyway. So.... what is the minimal compiler requirement to be? John.
I would like to add something here if I may. Those changes in dependencies between the several boost libraries can make it a lot harder to upgrade to a new release once it becomes available. I have a rule to always do that in order to avoid long term tech debt. So to have myself as an example, I usually have to patch new releases. At th every least Preprocessor, which I need to downgrade to 1.49's version because Incredibuild doesn't work properly with higher versions. Sometimes other libs because of specific problems or bugs. Now this in turn often forces me to downgrade or modify libs that are dependencies and those that are dependent. And there's the catch. It can be hard to figure out which exactly those are. If that changes so much between the releases this has to be done every time, defeating the purpose of the whole exercise. If I consider the release as an entity that I only need to plug and play (which would be the case in an ideal world) I wouldn't care much about the interdependencies among the submodules. Personally I would prefer heavy reuse among them to reduce bugs. But since above modifications are sadly regular practice for me I prefer transparent and clean dependencies. Just my 2 cents, Stephan On Wed, Jan 7, 2015 at 7:55 PM, Peter Dimov <lists@pdimov.com> wrote:
John Maddock wrote:
So.... what is the minimal compiler requirement to be?
Same as today's. I don't think that any Boost-supported compiler has trouble with simple C++03 SFINAE.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
Stephan Menzel wrote:
Now this in turn often forces me to downgrade or modify libs that are dependencies and those that are dependent. And there's the catch. It can be hard to figure out which exactly those are. If that changes so much between the releases this has to be done every time, defeating the purpose of the whole exercise.
You can in principle use the dependency report for that, although we aren't including one in the releases, so this advice of mine is of limited practical use at the moment. :-)
Getting back to the issue at hand (creating a "base" library), I would like to give my humble perspective on it. I think that the root of the problem is that a lot of the fundamental libraries in Boost, like type-traits, mpl, pp, utility, etc..., all have in common the fact that they have a few extremely useful components that are used widely both in the user-base at large and by other boost libraries (or could be used by them), and often those components were the original motivators for the creation of the library, but they also all have a number of additional "fancy" features that make sense within their prime application domains (and you can't blame library devs for wanting to fancy-up their libraries) but also constitute significant additional bloat for all those people who only need the few useful components. For instance, most people probably use the MPL for its basic meta-functions, especially the boolean stuff (if_, not_, and_...) for Sfinae and type selectors, but very few people need or want to use the whole "compile-time STL" part of MPL. The type-traits library is the same. And I think that if it were possible to distil things down to some basic components, much of the cross-dependencies and code-bloat would be eliminated, and other boost libraries could rely on those components without too much concern about getting bloated by them. I seems to me that the Boost.Core library is intended to regroup those things. But the real problem with getting a good set of components to put in Boost.Core is that there is no clear picture of what people want and what people don't want. The dependency analyser cannot capture things that people (from other boost libraries) would want to use but decided not to use (by implementing their own reduced version of it) for fear of too much bloat and dependencies, and nor is it really fine-grained enough for this purpose anyways. I think there might be a need for some form of voting/review system for people to be able to declare what specific components they would like to see added to Boost.Core (that would help them avoid the dilemma of dep./bloat versus code duplication) versus what specific components / features would need to be factored out of the code (or left out of boost.core) because of it being overly bloated. This would clearly have to be more fine-grained than just on a header-by-header basis. And the boost mailing list is far from providing an adequate forum for this type of thing. Or maybe people simply need to be more proactive in raising issues on Boost.Core's github, as I know people seem to still be just warming up to that mode of discussion. Of course, from a practical standpoint, this is difficult to realize, but I just felt I should throw that idea out there. P.S.: I find that this discussion also exemplifies what I see as a big problem with Boost discussions, that is, any decision-making discussion on broader issues quickly digresses into people raising their favourite pet-peeves (like compiler support reqs, git submoduling, distribution issues, etc.) and discussing small examples at length (like integral-constant). Cheers, Mikael.
On January 7, 2015 2:02:24 PM EST, Mikael Persson <mikael.s.persson@gmail.com> wrote:
P.S.: I find that this discussion also exemplifies what I see as a big problem with Boost discussions, that is, any decision-making discussion on broader issues quickly digresses into people raising their favourite pet-peeves (like compiler support reqs, git submoduling, distribution issues, etc.) and discussing small examples at length (like integral-constant).
I fail to see how those issues raised in this discussion were not relevant. The discussion is exploring the various effects of the proposal. If you think an issue is off topic for a particular discussion, post a reply that tries to restore focus. IOW, the responsibility to keep discussions focused lies with the community. ___ Rob (Sent from my portable computation engine)
El 07/01/2015 a las 17:48, Nevin Liber wrote:
On 7 January 2015 at 09:22, Beman Dawes <bdawes@acm.org> wrote:
For all the type traits that are now supported by the standard library in use, it might be nice if #include <boost/type_traits/std/some_trait.hpp> brought in the standard library version. So eventually the many boost libraries that use only type traits that have been standardized would have no dependencies on the actual boost implementations.
In order to do that, we need to somehow unify the following unrelated types:
std::integral_constant<bool, b> boost::integral_constant<bool, b> boost::mpl::integral_c<bool, b>
We could try to improve interoperability with a type that accepts anything that seems a true/false-type. Something like: namespace boost { namespace core_traits { template<bool Value> struct bool_type { template<class BoolType> bool_type (BoolType , enable_if_internal_bool_value_is_equal_to <Value>::type * = 0 ); }; } //namespace core_traits { } //namespace boost { So every custom integral_constant would be convertible to bool_type, and a very basic trait that does not derive from integral_constant: template<class T> struct is_mytrait { static const bool value = /**/; }; could be used with tag dispatching or enable_if + is_convertible. Best, Ion
On 01/07/2015 07:22 AM, Beman Dawes wrote:
On Wed, Jan 7, 2015 at 8:33 AM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
El 07/01/2015 a las 10:49, Antony Polukhin escribió:
Hi all,
I've been looking through the latest changes to drop dependencies. Stuff that I saw is very frightening.
For example:
https://github.com/boostorg/move/blob/develop/include/boost/move/detail/type... . Every boost release some issues are fixed in intrinsics of TypeTraits and is_move_* is_nothrow_* traits. Copy-pasting code from TypeTraits feels like loading a gun and pointing it on own foot.
I really don't agree. I've measured the code bloat that TypeTraits and other "low-level" libraries were bringing to some libraries and it was very noticeable. I would like to depend only on TypeTraits but that's impossible, it brings MPL, Preprocessor, etc. Including boost/container/vector.hpp was bringing MB of preprocessed lines, comparing it to 200KB of preprocessed code for <vector> and several users were complaining about compilation times. Compilation times have improved with the dependency removal. I've contributed a little bit to Boost.TypeTraits and I'd like to use it, but only if we can make Boost.TypeTraits depend only on Config/Predef.
For all the type traits that are now supported by the standard library in use, it might be nice if #include <boost/type_traits/std/some_trait.hpp> brought in the standard library version. So eventually the many boost libraries that use only type traits that have been standardized would have no dependencies on the actual boost implementations.
This worries me. I have had mixed results with type traits specifically and the behaviour of the Boost flavour versus the std flavour from various vendors. I don't recall the specifics right now except to recall that the std::is_pod in MSVC produced different results than gcc and Boost. I would rather see these choices be more implicit. I am not a fan of auto-selecting between the vendor version or the Boost version for any library. It creates more surprises than I like. michael -- Michael Caisse ciere consulting ciere.com
Michael Caisse wrote:
This worries me. I have had mixed results with type traits specifically and the behaviour of the Boost flavour versus the std flavour from various vendors. I don't recall the specifics right now except to recall that the std::is_pod in MSVC produced different results than gcc and Boost.
Our practice has generally been to not use the std version of something if it fails our tests, although there's always the possibility that your code happens to not be covered by our test suite.
On 01/07/2015 11:40 AM, Peter Dimov wrote:
Michael Caisse wrote:
This worries me. I have had mixed results with type traits specifically and the behaviour of the Boost flavour versus the std flavour from various vendors. I don't recall the specifics right now except to recall that the std::is_pod in MSVC produced different results than gcc and Boost.
Our practice has generally been to not use the std version of something if it fails our tests, although there's always the possibility that your code happens to not be covered by our test suite.
Yes, I understand that. We discussed this practice in May when the steering committee met and so I was bringing it up again partially as a reminder. I find the practice very surprising as a user and would prefer that it was controlled by a preprocessor flag and not done automagically. We might be all excited about std versions of things but at the end of the day 1. we don't control them, and 2. they are not the Boost implementation and may have different behaviour (performance, results, side affects ...). The subject came up as we were discussing this general practice and what to do with C++11 std libraries that overlap Boost. I'm somewhat opposed to the TR1 type thing we did where we automagically swap out implementations with the vendor version. I'm not opposed to using the vendor version but I think we need to provide control so that when something breaks for the user they can move back to the Boost version. michael -- Michael Caisse ciere consulting ciere.com
Michael Caisse wrote:
I'm not opposed to using the vendor version but I think we need to provide control so that when something breaks for the user they can move back to the Boost version.
A compiler-provided std::is_something breaking uses of boost::is_something (with the latter implemented in terms of the former) is not any different from a compiler bug breaking uses of boost::is_something (implemented independently of std::is_something). The effects and the mitigations are the same in both cases. Either way, I think that the more important effect of Beman's suggestion is not that the trait may pick up the std one's bugs, but that users of the trait will no longer be allowed to depend on Boost-specific parts of the interface that are not present in the std trait, such as an mpl::bool_ base class.
Either way, I think that the more important effect of Beman's suggestion is not that the trait may pick up the std one's bugs, but that users of the trait will no longer be allowed to depend on Boost-specific parts of the interface that are not present in the std trait, such as an mpl::bool_ base class.
Also, `mpl::bool_` more closely matches `std::integral_constant` in C++14 rather than C++11. So it could cause code to break if type traits were directly swapped out with std traits in C++11. Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Road-to-low-quality-code-is-paved-with-go... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 2015-01-07 20:33, Michael Caisse wrote:
On 01/07/2015 07:22 AM, Beman Dawes wrote:
For all the type traits that are now supported by the standard library in use, it might be nice if #include <boost/type_traits/std/some_trait.hpp> brought in the standard library version. So eventually the many boost libraries that use only type traits that have been standardized would have no dependencies on the actual boost implementations.
This worries me. I have had mixed results with type traits specifically and the behaviour of the Boost flavour versus the std flavour from various vendors. I don't recall the specifics right now except to recall that the std::is_pod in MSVC produced different results than gcc and Boost.
That was a bug in MSVC8. Should that affect boost forever?
I would rather see these choices be more implicit. I am not a fan of auto-selecting between the vendor version or the Boost version for any library. It creates more surprises than I like.
It would be a lot of configurations if you want to select each feature individually. Don't know if anyone really want to do that instead of waiting for a bug workaround in the next boost release. Bo Persson
On 7 January 2015 at 09:49, Antony Polukhin <antoshkka@gmail.com> wrote:
hash_fwd.hpp must be used by almost all the containers and structures
FWIW I'm fine with moving hash_fwd.hpp into core, or somewhere else. Its intent was always to break the dependency on the rest of the hash implementation, and if the dependency system can't understand that, then it isn't doing its job.
Daniel James wrote:
FWIW I'm fine with moving hash_fwd.hpp into core, or somewhere else. Its intent was always to break the dependency on the rest of the hash implementation, and if the dependency system can't understand that, then it isn't doing its job.
Creating a dependency system that will live up to everyone's expectations is not as easy as it sounds. To take hash_fwd as an example, suppose X uses hash_fwd.hpp, and Hash uses Y. The user installs X, which has to install Hash to get hash_fwd.hpp. Since the package Hash is now installed, it is listed in index.html, the users sees it as available, and tries to make use of it. If Y was not installed along with it, use of Hash would fail, and this isn't user friendly. You can get this behavior today, if you move hash_fwd.hpp to a submodule hash/fwd, but since the installer operates on packages, and hash/fwd is in the 'hash' package, the problem I outlined above will manifest. (Even if we ignore the fact that Hash is actually in the package 'functional', so things are even more coarse-grained than that.)
On 7 January 2015 at 15:19, Peter Dimov <lists@pdimov.com> wrote:
Daniel James wrote:
FWIW I'm fine with moving hash_fwd.hpp into core, or somewhere else. Its intent was always to break the dependency on the rest of the hash implementation, and if the dependency system can't understand that, then it isn't doing its job.
Creating a dependency system that will live up to everyone's expectations is not as easy as it sounds. To take hash_fwd as an example, suppose X uses hash_fwd.hpp, and Hash uses Y. The user installs X, which has to install Hash to get hash_fwd.hpp. Since the package Hash is now installed, it is listed in index.html, the users sees it as available, and tries to make use of it. If Y was not installed along with it, use of Hash would fail, and this isn't user friendly.
I meant the header isn't doing its job, which is why I was saying it's okay to move it into core, as that would fix the problem you're describing.
You can get this behavior today, if you move hash_fwd.hpp to a submodule hash/fwd, but since the installer operates on packages, and hash/fwd is in the 'hash' package, the problem I outlined above will manifest. (Even if we ignore the fact that Hash is actually in the package 'functional', so things are even more coarse-grained than that.)
Hash isn't the package 'functional', it's in the git submodule 'functional'. I'm certainly not having a git submodule just for one header. They're way too expensive.
Daniel James wrote:
I'm certainly not having a git submodule just for one header. They're way too expensive.
In what way are git submodules expensive? (Note: this is not an argument in favor of making a git submodule for hash_fwd.hpp. It is a genuine question that will help my evaluation of the various tradeoffs.)
On 7 January 2015 at 18:24, Peter Dimov <lists@pdimov.com> wrote:
Daniel James wrote:
I'm certainly not having a git submodule just for one header. They're way too expensive.
In what way are git submodules expensive?
Expensive both in terms of developer effort (managing multiple repos, pull requests, etc.) and git running time. Also, more directories in libs to deal with.
Daniel James wrote:
Hash isn't the package 'functional', it's in the git submodule 'functional'.
It's also in the package 'functional' (that is, it resides in the directory libs/functional and the package script and bpm at the moment do not support finer resolution than libs/*) and in the module 'functional' (it doesn't have its own include/ directory and is therefore not recognized as a submodule by boostdep). It should just be in libs/hash. For hash_fwd, we could in principle create a repository libs/fwd that will host all forwarding headers. This could be a good place for boost/detail/container_fwd.hpp, which currently resides in Detail for lack of a better home.
On 8 January 2015 at 05:27, Peter Dimov <lists@pdimov.com> wrote:
Daniel James wrote:
Hash isn't the package 'functional', it's in the git submodule 'functional'.
It's also in the package 'functional' (that is, it resides in the directory libs/functional and the package script and bpm at the moment do not support finer resolution than libs/*)
They probably should support a finer resolution, there are several examples of this in boost.
and in the module 'functional' (it doesn't have its own include/ directory and is therefore not recognized as a submodule by boostdep).
I would like to use 'libs/functional/hash/include' but our tools don't support it. There was an attempt to reorganise mpl along those lines, but it was abandoned. If it had been successful I would have done the same.
It should just be in libs/hash.
But it isn't. I'm not going to waste time moving things around now. I've already spent enough time cleaning up after other people moved things around. Maybe in the future.
For hash_fwd, we could in principle create a repository libs/fwd that will host all forwarding headers. This could be a good place for boost/detail/container_fwd.hpp, which currently resides in Detail for lack of a better home.
It's in detail because it shouldn't be public. It also has a different purpose to forwarding headers for boost libraries, so 'fwd' wouldn't be a good place for it. Anyway, it doesn't even work properly on most modern standard libraries (because of the way they use namespaces), and has to fall back to just including a load of standard headers, so it probably should be deprecated and eventually removed.
Daniel James wrote:
I would like to use 'libs/functional/hash/include' but our tools don't support it. There was an attempt to reorganise mpl along those lines, but it was abandoned. If it had been successful I would have done the same.
Our tools actually do support it. The problem with mpl was caused by #includes via a macro, which were accidentally working under the old organization and broke under the new one. That said,
It should just be in libs/hash.
is still the right thing to do.
But it isn't. I'm not going to waste time moving things around now.
<shrug> Suit yourself.
On 9 January 2015 at 16:30, Peter Dimov <lists@pdimov.com> wrote:
Daniel James wrote:
I would like to use 'libs/functional/hash/include' but our tools don't support it. There was an attempt to reorganise mpl along those lines, but it was abandoned. If it had been successful I would have done the same.
Our tools actually do support it.
Jamroot has still a special case for numeric, so that's at least one place where they don't.
Daniel James wrote:
Jamroot has still a special case for numeric, so that's at least one place where they don't.
C:\Projects\boost-git\boost>grep numeric Jamroot C:\Projects\boost-git\boost> This is on develop. Maybe master still has the numeric special case, I haven't checked. develop however now looks at libs/*/include and libs/*/*/include as far as I can see. chrono~stopwatches already takes advantage of this. local all-headers = [ MATCH .*libs/(.*)/include/boost : [ glob libs/*/include/boost libs/*/*/include/boost ] ] ; It doesn't seem to support building a submodule: all-libraries = [ MATCH .*libs/(.*)/build/.* : [ glob libs/*/build/Jamfile.v2 ] [ glob libs/*/build/Jamfile ] ] ; but that's fixable as well and doesn't matter at the moment. With all that said, I've recently grown a substantial dislike for submodules. libs/* is the way to go, even (eventually) for numeric.
On 9 January 2015 at 16:55, Peter Dimov <lists@pdimov.com> wrote:
Daniel James wrote:
Jamroot has still a special case for numeric, so that's at least one place where they don't.
C:\Projects\boost-git\boost>grep numeric Jamroot
C:\Projects\boost-git\boost>
This is on develop. Maybe master still has the numeric special case, I haven't checked.
You should have. Nothing is supported until it's supported in master, or to be more accurate, in a release.
chrono~stopwatches already takes advantage of this.
That isn't included in the test results, and the headers aren't installed in the release.
Daniel James wrote:
On 8 January 2015 at 05:27, Peter Dimov <lists@pdimov.com> wrote:
It [hash] 's also in the package 'functional' (that is, it resides in the directory libs/functional and the package script and bpm at the moment do not support finer resolution than libs/*)
They probably should support a finer resolution, there are several examples of this in boost.
Tradeoffs here. Nested packages (one in functional/, the other in functional/hash/) present a slight problem for bpm in that it can't just nuke libs/functional when told to remove 'functional', as it currently does. It obviously _can_ be made smarter about it, but this would require keeping metadata about what's installed and what isn't, with the potential of said metadata going out of sync with what's actually installed, being deleted by the user, and so on. Currently, you can manually delete libs/functional instead of bpm remove -f functional, both do the same thing. This simplicity of operation has its benefits for users (it's not just for my convenience).
participants (15)
-
Antony Polukhin -
Beman Dawes -
Bo Persson -
Daniel James -
Ion Gaztañaga -
John Maddock -
Kolya Kosenko -
Michael Caisse -
Mikael Persson -
Nevin Liber -
Peter Dimov -
pfultz2 -
Rene Rivera -
Rob Stewart -
Stephan Menzel