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] active gcc/kernel/... dependencies (was: tr1 dependencies)
On Tue, 30 Jan 2007 14:49:48 +0100 Matthias Langer [EMAIL PROTECTED] wrote: 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 ... Sure you can check for it, but not at dependency calculation time. A useflag won't help there, would be the same as a || dependency, just worse. Marius -- 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
[gentoo-dev] Re: active gcc/kernel/... dependencies (was: tr1 dependencies)
Marius Mauch [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 30 Jan 2007 16:49:51 +0100: On Tue, 30 Jan 2007 14:49:48 +0100 Matthias Langer [EMAIL PROTECTED] wrote: 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 ... Sure you can check for it, but not at dependency calculation time. A useflag won't help there, would be the same as a || dependency, just worse. What about a USE flag set by the profile (there's a boost use flag already, however, so that's out unless usage can be made compatible with the profile-masking bit)? Archs that don't have gcc-4.1 can mask the flag and hard-set the dependency to boost. Those that have it stable can mask it and hard-set the gcc-4.1 dependency. Those that have gcc-4.1 as unstable can unmask the useflag and default it to boost. Ebuilds using the flag could set an ewarn or elog that warns appropriately about having to run revdep-rebuild or emerge -N if the flag is changed or boost unmerged, and the rest could be handled in profile upgrade documentation where it applies. This should certainly be sufficient for non-toolchain. If there's a toolchain dependency, things get a bit more hairy, but profile changes and possibly having an emergency binary tarballed version if appropriate, preferably built with the dependency static, should still handle it. With the transfer to profile-controlled multilib, I know amd64 had a couple hairy profile upgrades where a multilib gcc binary tarball came in handy. IIRC there was a flag set in the profile change that the profile's bashrc tested for and warned about if the profile switching instructions hadn't been followed, and emerge wouldn't do much until the profile was switched back and the profile switched to following the instructions if desired, so it can be done. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- 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
[gentoo-dev] make_desktop_entry in eutils.eclass
I have a few suggestions for the make_desktop_entry function in eutils.eclass: 1 - Allow me to pass in a full application path. If you pass in the full path to an executable as the first argument, it comes up with a crazy filename like this: /var/tmp/portage/rox-base/mime-editor-0.5/temp//usr/lib/rox/MIME-Editor/AppRun-mime-editor.desktop When a more appropriate name would be: /var/tmp/portage/rox-base/mime-editor-0.5/temp/AppRun-mime-editor.desktop In other words, I propose that this function should probably do 'basename' on $exec before using it for the .desktop filename. 2 - Allow me to explicitly set the name of the .desktop file. This would perhaps solve #1 above as well. I propose an optional environment variable an ebuild can set before calling make_desktop_entry, called DESKTOP_BASENAME, which would be the basename of the file (not including the .desktop suffix) that the function would use (if set) to create the file. 3 - Allow me to add other important settings like 'NoDisplay', 'OnlyShowIn', and/or 'MimeType'. I propose an optional environment variable 'DESKTOP_EXTRAS' that the ebuild could set before calling make_desktop_entry. This would be an actual verbatim (newline-delimited) copy of the extra lines to be added to the desktop file, for example: DESKTOP_EXTRAS=OnlyShowIn=Yes or DESKTOP_EXTRAS=MimeType=text/plain NoDisplay=Yes Any objections? Suggestions? I would be willing to add these myself if no one else is. -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
Re: [gentoo-dev] make_desktop_entry in eutils.eclass
On Tuesday 30 January 2007 16:10, Jim Ramsay wrote: In other words, I propose that this function should probably do 'basename' on $exec before using it for the .desktop filename. no ... the point of using $exec is to make sure the .desktop file is unique i'll change it to sanitize the filename and turn them into underscores I propose an optional environment variable an ebuild can set before calling make_desktop_entry, called DESKTOP_BASENAME, which would be the basename of the file (not including the .desktop suffix) that the function would use (if set) to create the file. env vars to functions are lame 3 - Allow me to add other important settings like 'NoDisplay', 'OnlyShowIn', and/or 'MimeType'. at this point, you might as well write your own .desktop file -mike pgpSoHUlKA305.pgp Description: PGP signature
[gentoo-portage-dev] [RFC] Depending on active version
Sometimes a package has to depend on a specific version of a slotted package being the active one to build correctly, like in the current tr1 discussion on -dev [1] or with packages that depend on the running kernel. Currently this isn't really possible, however I while ago I got an idea how to solve this. Keep in mind this is just a rough idea and I'm pretty sure some people can/will point out why it is a stupid idea, but anyway: The idea is to add a special category (let's call it active for now) that has the following properties: - this category doesn't exist in portdir or vdb (= no ebuilds) - when portage ($pkgmanager) encounters a active/foo atom in a dependency string it executes some special code (e.g. $PORTDIR/scripts/active-check/foo =active/foo-1) to determine if that atom is satisfied (and yes, this kinda goes with multi-repo/multi-format support) Marius -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Depending on active version
On Tue, Jan 30, 2007 at 05:06:51PM +0100, Marius Mauch wrote: Sometimes a package has to depend on a specific version of a slotted package being the active one to build correctly, like in the current tr1 discussion on -dev [1] or with packages that depend on the running kernel. tr1 is partially addressed via addition of a 'binding' modifier for rdeps, to state that ||() deps are locked down after compilation. Doesn't gurantee the user doesn't pop back to 3.4 after compilation, but that's their own mess. The idea is to add a special category (let's call it active for now) that has the following properties: - this category doesn't exist in portdir or vdb (= no ebuilds) - when portage ($pkgmanager) encounters a active/foo atom in a dependency string it executes some special code (e.g. $PORTDIR/scripts/active-check/foo =active/foo-1) to determine if that atom is satisfied Non deterministic resolution; previous steps in the graph can cause that value to flip to a different setting by the time the 'dep' is encountered. That's ignoring the kick in the nads usage of this will due to resolution... (and yes, this kinda goes with multi-repo/multi-format support) Don't really see how this enables multiple standalone repos in any sane way, so that one requires justification... ~harring pgpetWeCOF0tF.pgp Description: PGP signature
Re: [gentoo-portage-dev] [RFC] Depending on active version
Marius Mauch wrote: Sometimes a package has to depend on a specific version of a slotted package being the active one to build correctly, like in the current tr1 discussion on -dev [1] or with packages that depend on the running kernel. Currently this isn't really possible, however I while ago I got an idea how to solve this. Keep in mind this is just a rough idea and I'm pretty sure some people can/will point out why it is a stupid idea, but anyway: The idea is to add a special category (let's call it active for now) that has the following properties: - this category doesn't exist in portdir or vdb (= no ebuilds) - when portage ($pkgmanager) encounters a active/foo atom in a dependency string it executes some special code (e.g. $PORTDIR/scripts/active-check/foo =active/foo-1) to determine if that atom is satisfied (and yes, this kinda goes with multi-repo/multi-format support) Marius I don't see why how this is any less complicated than just adding more functionality to || deps (runtime versus compile time) -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Depending on active version
On Tue, 30 Jan 2007 08:25:31 -0800 Brian Harring [EMAIL PROTECTED] wrote: On Tue, Jan 30, 2007 at 05:06:51PM +0100, Marius Mauch wrote: Sometimes a package has to depend on a specific version of a slotted package being the active one to build correctly, like in the current tr1 discussion on -dev [1] or with packages that depend on the running kernel. tr1 is partially addressed via addition of a 'binding' modifier for rdeps, to state that ||() deps are locked down after compilation. And how would that solve the actual issue of expressing I need /usr/bin/gcc to run gcc-4.1 and not gcc-3.4? The lockdown of || deps is a completely separate issue, unless I'm missing something. The idea is to add a special category (let's call it active for now) that has the following properties: - this category doesn't exist in portdir or vdb (= no ebuilds) - when portage ($pkgmanager) encounters a active/foo atom in a dependency string it executes some special code (e.g. $PORTDIR/scripts/active-check/foo =active/foo-1) to determine if that atom is satisfied Non deterministic resolution; previous steps in the graph can cause that value to flip to a different setting by the time the 'dep' is encountered. Ok, that's a problem, though for the use cases at hand (gcc and kernel) it would be mostly irrelevant. That's ignoring the kick in the nads usage of this will due to resolution... Neglectable IMO, it's not such a common use case anyway, and I don't think I have to compare it to the current solution (die in setup or compile). (and yes, this kinda goes with multi-repo/multi-format support) Don't really see how this enables multiple standalone repos in any sane way, so that one requires justification... Where did I say anything about enabling? It would need more or less a separate repository (dbapi) instance, so it would require such support. Marius -- gentoo-portage-dev@gentoo.org mailing list
