Re: [gentoo-dev] tr1 dependencies
On Wed, 31 Jan 2007 23:26:06 + Ciaran McCreesh [EMAIL PROTECTED] wrote: | virtual/tr1-memory | virtual/tr1-unordered-containers | virtual/tr1-random | virtual/tr1-regex | | Rather a lot of work, and rather icky... Looking at this some more... We're probably talking about needing the following new style virtuals: tr1-utilities (tuples and smart pointers) tr1-containers (array and unordered associative containers) tr1-call-wrappers (mem_fn, reference_wrapper, function, bind) tr1-type-traits tr1-numerics tr1-regex tr1-c-compatibility The category names match up with the chapter names in The C++ Standard Library Extensions (Pete Becker / Addison Wesley / 0-321-41299-0). In terms of providers: g++-4.1 has utilities, containers, call-wrappers and type-traits. g++-4.2 adds c-compatibility and numerics. boost has utilities, containers, call-wrappers, type-traits, numerics and regex, but in the wrong namespaces. There's a boost tr1 wrapper being developed, and everything I've seen that uses tr1 so far includes the namespace using wrappers to make boost an option. Also note that boost focuses more upon getting stuff to work with every single compiler than upon decent performance or making things not take weeks to compile -- most boost headers pull in several megs of other header files, which *really* hurts compile times. There are already quite a few packages out there using utilities and containers. So far tr2 isn't sufficiently standardised to be relevant to this discussion. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On 2007-01-30, Matthias Langer [EMAIL PROTECTED] wrote: nope ... let's hope c++-0x comes out soon and that compiler vendors are faster in implementing it than c++-98. It's actually officially called (skipping all the admin stuff): C++09 That gives a good indication of when it is likely to come out (at the earliest) :-) And, of course, the whole of this discussion is equally applicable for TR2. phil -- change name before @ to phil for email -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On Tue, 30 Jan 2007 11:11:20 -0500 (EST) Caleb Tennis
[EMAIL PROTECTED] wrote:
| * Hard dep upon boost. This sucks for g++-4.1 users.
|
| * Hard dep upon g++-4.1, which isn't available for all archs. This
| doesn't even work because there's no guarantee that =4.1 is being
| used even if it's installed.
|
| I don't think these are necessarily compatible. tr1 is implemented
| in the std::tr1, while I think everything in boost is just in the
| boost namespace (unless this has changed since I've used boost).
| This would mean that the project code itself would have to have the
| logic to decide which set of headers to use. I'm guessing most
| probably won't have the compatibility code to make that accessment,
| though some may.
Everything I've seen that uses tr1 can also use boost. The
compatibility code is just something like:
#include boost/shared_ptr.hpp
namespace std
{
namespace tr1
{
using boost::shared_ptr;
using boost::enable_shared_from_this;
using boost::static_pointer_cast;
// and anything else that's necessary
}
}
It's not exactly difficult to do...
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/
signature.asc
Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On Tue, 30 Jan 2007 10:47:09 -0600 Grant Goodyear [EMAIL PROTECTED] wrote: | * Hard dep upon g++-4.1, which isn't available for all archs. This | doesn't even work because there's no guarantee that =4.1 is being | used even if it's installed. | | I haven't done my homework, so I'll just ask: Is there a reasonable | timeframe for 4.1 on archs that we're using? Is there actual evidence | that tr1-using packages are going to become prevalent before 4.1+ | becomes ubiquitous? A few archs are having pretty big issues with 4.1. In the mean time, tr1 is so damned useful that programmers are going to take a lot of persuading *not* to use it. | An alternative, which would be a real pain, is to have g++-4.1 | ebuilds build boost tr1 libraries as part of the ebuild, and then | have compatibility libraries for people who remove old versions of | g++, just like we do now. The benefit would be that at the cost of | forcing everybody to upgrade g++ we could rely on tr1 existing | everywhere. Even that won't necessarily work, since g++-4.1 doesn't include a full tr1 implementation. It includes the useful stuff, but it's missing the random number and regex parts of the specification -- which, fortunately, are nowhere near as popular as hash tables and smart pointers. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
Ciaran McCreesh a écrit : * Hard dep upon boost. This sucks for g++-4.1 users. * Hard dep upon g++-4.1, which isn't available for all archs. This doesn't even work because there's no guarantee that =4.1 is being used even if it's installed. * || ( ) deps, and hope that if the user has 4.1 installed then they're using it. Since library implementations aren't runtime switchable, this will lead to breakages if users upgrade gcc and then remove boost. None of these are particularly nice... Newbie idea : g++ and boost both provide virtual/tr1 Newbie question : besides the fact that you would have to rebuild packages if you changed the virtual, is there anything painfully obvious why that would be a bad idea ? Just a thought :) Rémi -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On Wed, 31 Jan 2007 23:36:33 +0100 Rémi Cardona [EMAIL PROTECTED] wrote: Newbie idea : g++ and boost both provide virtual/tr1 Newbie question : besides the fact that you would have to rebuild packages if you changed the virtual, is there anything painfully obvious why that would be a bad idea ? And what exactly is required of a package providing virtual/tr1? If it has to implement the entirity of the TR, then g++-4.1 can't provide the virtual and the purpose is lost since the most used parts of the extension will be those provided by GCC. If, on the other hand, you require the virtual to provide only the parts currently implemented in g++, what happens in the future for packages that require other parts of the tr1 extension? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On Wed, 31 Jan 2007 23:24:31 + Stephen Bennett [EMAIL PROTECTED] wrote: | And what exactly is required of a package providing virtual/tr1? If it | has to implement the entirity of the TR, then g++-4.1 can't provide | the virtual and the purpose is lost since the most used parts of the | extension will be those provided by GCC. If, on the other hand, you | require the virtual to provide only the parts currently implemented in | g++, what happens in the future for packages that require other parts | of the tr1 extension? Mmm. Well... virtual/tr1-memory virtual/tr1-unordered-containers virtual/tr1-random virtual/tr1-regex Rather a lot of work, and rather icky... -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On Wed, Jan 31, 2007 at 11:24:31PM +, Stephen Bennett wrote: On Wed, 31 Jan 2007 23:36:33 +0100 Rémi Cardona [EMAIL PROTECTED] wrote: Newbie idea : g++ and boost both provide virtual/tr1 Newbie question : besides the fact that you would have to rebuild packages if you changed the virtual, is there anything painfully obvious why that would be a bad idea ? And what exactly is required of a package providing virtual/tr1? If it has to implement the entirity of the TR, then g++-4.1 can't provide the virtual and the purpose is lost since the most used parts of the extension will be those provided by GCC. You're ignoring that new style virtuals can have versions; thus virtual/tr-[arbitrary version 1] can be 'almost full 1 support'. Yes, mildly hackish, but it address that concern. As for whatever I build against, I hard RDEP on, as said elsewhere, need a way to specify that an rdep is 'binding', non changable. ~harring pgpPz9cjol1cf.pgp Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On Wed, 31 Jan 2007 15:32:03 -0800 Brian Harring [EMAIL PROTECTED] wrote: | You're ignoring that new style virtuals can have versions; thus | virtual/tr-[arbitrary version 1] | can be 'almost full 1 support'. Which means what, in terms of parts of tr1 that are and aren't supplied by various people? There's no nice neat linear progression there, beyond most things requiring a few of the new basic utilities. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On Wed, Jan 31, 2007 at 11:38:04PM +, Ciaran McCreesh wrote: On Wed, 31 Jan 2007 15:32:03 -0800 Brian Harring [EMAIL PROTECTED] wrote: | You're ignoring that new style virtuals can have versions; thus | virtual/tr-[arbitrary version 1] | can be 'almost full 1 support'. Which means what, in terms of parts of tr1 that are and aren't supplied by various people? There's no nice neat linear progression there, beyond most things requiring a few of the new basic utilities. The linear progression would be made up as you go- admittedly, if a third provider shows up, scheme goes to hell. Don't claim it's the best notion, but it's definitely a fallback option assuming nothing decent is found. ~harring pgpLPIA0g6qwv.pgp Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On Wed, 31 Jan 2007 16:00:49 -0800 Brian Harring [EMAIL PROTECTED] wrote: | On Wed, Jan 31, 2007 at 11:38:04PM +, Ciaran McCreesh wrote: | On Wed, 31 Jan 2007 15:32:03 -0800 Brian Harring | [EMAIL PROTECTED] wrote: | | You're ignoring that new style virtuals can have versions; thus | | virtual/tr-[arbitrary version 1] | | can be 'almost full 1 support'. | | Which means what, in terms of parts of tr1 that are and aren't | supplied by various people? There's no nice neat linear progression | there, beyond most things requiring a few of the new basic | utilities. | | The linear progression would be made up as you go- admittedly, if a | third provider shows up, scheme goes to hell. A third provider like STLport or icc? STLport already supports tr1 hash tables... -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On Tue, 30 Jan 2007 08:41:56 +0100 Luca Barbato [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Tue, 30 Jan 2007 08:30:40 +0100 Luca Barbato [EMAIL PROTECTED] | wrote: | | Ciaran McCreesh wrote: | | What is the best way to handle packages that require parts of | | tr1? The options appear to be: | | | | * have the application bundle a static implementation and switch | | to system on at configure time as done for other libs? | | At something like five megs of code per application? | | fine by me. (5mb if you use everything, less if you use just certain | bits I hope) If you're using boost as your source (pretty much the only way that doesn't involve either paying money or only supporting compilers that already ship tr1 anyway), pulling in even a little bit of the library will almost certainly require a large chunk of boost. For example, to use just the shared_ptr code, bcp says you need: * boost.config (250KBytes) * the boost preprocessor library (2MBytes) * the boost type traits library (670KBytes) * the boost metaprogramming library (200KBytes) * various other random smaller things bringing it up to 3.3MBytes of code, about 3.2MBytes of which is compiler bug workarounds and boost-review-process-induced mutual masturbation. The entire tr1/memory implementation that's shipped with g++-4.1, meanwhile, is something like 30KBytes. Unfortunately it only works g++-4.1, so it's no use for bundling as part of an application. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
Ciaran McCreesh wrote: bringing it up to 3.3MBytes of code, about 3.2MBytes of which is compiler bug workarounds and boost-review-process-induced mutual masturbation. So the safest route is either bundle boost (that is heavy as you shown in detail) and/or just depend on it at least for now. A tinytr1 ripped from boost probably would be the perfect solution =/ The entire tr1/memory implementation that's shipped with g++-4.1, meanwhile, is something like 30KBytes. Unfortunately it only works g++-4.1, so it's no use for bundling as part of an application. pity =/ lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On 30.01.2007, at 09:36, Ciaran McCreesh wrote: | * have the application bundle a static implementation and switch to | system on at configure time as done for other libs? At something like five megs of code per application? If you make that decidable by a USE-flag like minimal? Philipp -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On Tue, 30 Jan 2007 11:36:35 +0200 Philipp Riegger [EMAIL PROTECTED] wrote: | On 30.01.2007, at 09:36, Ciaran McCreesh wrote: | | | * have the application bundle a static implementation and switch | | to system on at configure time as done for other libs? | | At something like five megs of code per application? | | If you make that decidable by a USE-flag like minimal? Which solves what, for your average user? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On Tue, 2007-01-30 at 06:27 +, Ciaran McCreesh wrote: [ Background: tr1 is a set of extensions to the C++ Standard Library giving various useful things like hash tables and smart pointers. There are partial implementations included in g++-4.1 and boost and full implementations available from Dinkumware. It is likely that a lot of C++ apps will start using it in the not too distant future. ] What is the best way to handle packages that require parts of tr1? The options appear to be: * Hard dep upon boost. This sucks for g++-4.1 users. * Hard dep upon g++-4.1, which isn't available for all archs. This doesn't even work because there's no guarantee that =4.1 is being used even if it's installed. isn't it possible to check the version of gcc that is in _use_ in an ebuild, like i can do in a configure script? if so, one could provide a old-gcc use flag that must be enabled when trying to build with gcc-4.1.0 (that actually pulls in boost etc.) and must not be enabled when using =gcc-4.1.0 ... * || ( ) deps, and hope that if the user has 4.1 installed then they're using it. Since library implementations aren't runtime switchable, this will lead to breakages if users upgrade gcc and then remove boost. switching gcc versions may lead to breakage anyway if the user doesn't know what he/she is doing. None of these are particularly nice... nope ... let's hope c++-0x comes out soon and that compiler vendors are faster in implementing it than c++-98. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On 30.01.2007, at 11:40, Ciaran McCreesh wrote: | | * have the application bundle a static implementation and switch | | to system on at configure time as done for other libs? | | At something like five megs of code per application? | | If you make that decidable by a USE-flag like minimal? Which solves what, for your average user? If the user decides to have a minimal installation, he has to take care not to break it. BTW, doesn't revdep-rebuild find the problems in such a minimal installation? Philipp -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
* Hard dep upon boost. This sucks for g++-4.1 users. * Hard dep upon g++-4.1, which isn't available for all archs. This doesn't even work because there's no guarantee that =4.1 is being used even if it's installed. I don't think these are necessarily compatible. tr1 is implemented in the std::tr1, while I think everything in boost is just in the boost namespace (unless this has changed since I've used boost). This would mean that the project code itself would have to have the logic to decide which set of headers to use. I'm guessing most probably won't have the compatibility code to make that accessment, though some may. Caleb -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
Ciaran McCreesh wrote: [Tue Jan 30 2007, 12:27:49AM CST] * Hard dep upon boost. This sucks for g++-4.1 users. Agreed. Worse, it's a stop-gap measure, since presumably the long term solution is for tr1 to be supported directly by the compiler on all archs. So, any work done with this approach would just have to be undone in the future. * Hard dep upon g++-4.1, which isn't available for all archs. This doesn't even work because there's no guarantee that =4.1 is being used even if it's installed. I haven't done my homework, so I'll just ask: Is there a reasonable timeframe for 4.1 on archs that we're using? Is there actual evidence that tr1-using packages are going to become prevalent before 4.1+ becomes ubiquitous? An alternative, which would be a real pain, is to have g++-4.1 ebuilds build boost tr1 libraries as part of the ebuild, and then have compatibility libraries for people who remove old versions of g++, just like we do now. The benefit would be that at the cost of forcing everybody to upgrade g++ we could rely on tr1 existing everywhere. *Shrug* Hopefully somebody has a better idea. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpsBe3vc7jjD.pgp Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
Ciaran McCreesh wrote: What is the best way to handle packages that require parts of tr1? The options appear to be: * have the application bundle a static implementation and switch to system on at configure time as done for other libs? lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On Tue, 30 Jan 2007 08:30:40 +0100 Luca Barbato [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | What is the best way to handle packages that require parts of tr1? | The options appear to be: | | | * have the application bundle a static implementation and switch to | system on at configure time as done for other libs? At something like five megs of code per application? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
Ciaran McCreesh wrote: On Tue, 30 Jan 2007 08:30:40 +0100 Luca Barbato [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | What is the best way to handle packages that require parts of tr1? | The options appear to be: | | | * have the application bundle a static implementation and switch to | system on at configure time as done for other libs? At something like five megs of code per application? fine by me. (5mb if you use everything, less if you use just certain bits I hope) lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
