* [gentoo-dev] RFC: c++14 global USE flag @ 2015-04-24 18:12 Maxim Koltsov 2015-04-24 18:42 ` Ciaran McCreesh 0 siblings, 1 reply; 26+ messages in thread From: Maxim Koltsov @ 2015-04-24 18:12 UTC (permalink / raw To: gentoo-dev@lists.gentoo.org [-- Attachment #1: Type: text/plain, Size: 525 bytes --] Hello. My previous email was sent from the wrong address and it seems it did not make it into the list. Sending again from the right address... I'm introducing "c++14" use flag to every package in app-leechcraft catherogy via leechcraft.eclass. I need to put USE description somewhere. I propose / ask for permission to do it in global use.desc. Putting this flag to every single metadata.xml feels just wrong --- there are 72 of them now. Proposed description: "Build using C++ 14 standard" Looking forward for comments. [-- Attachment #2: Type: text/html, Size: 674 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] RFC: c++14 global USE flag 2015-04-24 18:12 [gentoo-dev] RFC: c++14 global USE flag Maxim Koltsov @ 2015-04-24 18:42 ` Ciaran McCreesh 2015-04-24 18:56 ` Ian Stakenvicius 0 siblings, 1 reply; 26+ messages in thread From: Ciaran McCreesh @ 2015-04-24 18:42 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 763 bytes --] On Fri, 24 Apr 2015 21:12:32 +0300 Maxim Koltsov <maksbotan@gentoo.org> wrote: > Hello. My previous email was sent from the wrong address and it seems > it did not make it into the list. Sending again from the right > address... > > I'm introducing "c++14" use flag to every package in app-leechcraft > catherogy via leechcraft.eclass. I need to put USE description > somewhere. I propose / ask for permission to do it in global use.desc. > Putting this flag to every single metadata.xml feels just wrong --- > there are 72 of them now. > > Proposed description: > "Build using C++ 14 standard" > > Looking forward for comments. This isn't going to be sustainable... What's the long-term plan for dealing with this? -- Ciaran McCreesh [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] RFC: c++14 global USE flag 2015-04-24 18:42 ` Ciaran McCreesh @ 2015-04-24 18:56 ` Ian Stakenvicius 2015-04-24 19:11 ` Maxim Koltsov 2015-04-25 14:09 ` Anthony G. Basile 0 siblings, 2 replies; 26+ messages in thread From: Ian Stakenvicius @ 2015-04-24 18:56 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24/04/15 02:42 PM, Ciaran McCreesh wrote: > On Fri, 24 Apr 2015 21:12:32 +0300 Maxim Koltsov > <maksbotan@gentoo.org> wrote: >> Hello. My previous email was sent from the wrong address and it >> seems it did not make it into the list. Sending again from the >> right address... >> >> I'm introducing "c++14" use flag to every package in >> app-leechcraft catherogy via leechcraft.eclass. I need to put USE >> description somewhere. I propose / ask for permission to do it in >> global use.desc. Putting this flag to every single metadata.xml >> feels just wrong --- there are 72 of them now. >> >> Proposed description: "Build using C++ 14 standard" >> >> Looking forward for comments. > > This isn't going to be sustainable... What's the long-term plan > for dealing with this? > Sounds like we need to go through the archives and revisit the conversations about how to integrate c++11 , again.. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlU6kfYACgkQ2ugaI38ACPCDuQEAhAv0boCkTU3RvT5d/fX3la7V 8so0wqnPtHKI4fSqEwgA+wXmVlB14ykbTQ1VnrRR5WrEPRjMbm9V1MSXAA6MnC43 =i/3U -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] RFC: c++14 global USE flag 2015-04-24 18:56 ` Ian Stakenvicius @ 2015-04-24 19:11 ` Maxim Koltsov 2015-04-24 19:28 ` Georg Rudoy 2015-04-25 14:09 ` Anthony G. Basile 1 sibling, 1 reply; 26+ messages in thread From: Maxim Koltsov @ 2015-04-24 19:11 UTC (permalink / raw To: gentoo-dev@lists.gentoo.org, Георгий Рудой [-- Attachment #1: Type: text/plain, Size: 1539 bytes --] 2015-04-24 21:56 GMT+03:00 Ian Stakenvicius <axs@gentoo.org>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 24/04/15 02:42 PM, Ciaran McCreesh wrote: > > On Fri, 24 Apr 2015 21:12:32 +0300 Maxim Koltsov > > <maksbotan@gentoo.org> wrote: > >> Hello. My previous email was sent from the wrong address and it > >> seems it did not make it into the list. Sending again from the > >> right address... > >> > >> I'm introducing "c++14" use flag to every package in > >> app-leechcraft catherogy via leechcraft.eclass. I need to put USE > >> description somewhere. I propose / ask for permission to do it in > >> global use.desc. Putting this flag to every single metadata.xml > >> feels just wrong --- there are 72 of them now. > >> > >> Proposed description: "Build using C++ 14 standard" > >> > >> Looking forward for comments. > > > > This isn't going to be sustainable... What's the long-term plan > > for dealing with this? > > > > Sounds like we need to go through the archives and revisit the > conversations about how to integrate c++11 , again.. > > This is temporal, until gcc gets needed support and that version makes its way into ~. Then the flag won't be needed anymore, we'll just depend on new enough gcc and enable C++14 mode by default. I'm CCing LeechCraft author just in case. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iF4EAREIAAYFAlU6kfYACgkQ2ugaI38ACPCDuQEAhAv0boCkTU3RvT5d/fX3la7V > 8so0wqnPtHKI4fSqEwgA+wXmVlB14ykbTQ1VnrRR5WrEPRjMbm9V1MSXAA6MnC43 > =i/3U > -----END PGP SIGNATURE----- > > [-- Attachment #2: Type: text/html, Size: 2337 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] RFC: c++14 global USE flag 2015-04-24 19:11 ` Maxim Koltsov @ 2015-04-24 19:28 ` Georg Rudoy 0 siblings, 0 replies; 26+ messages in thread From: Georg Rudoy @ 2015-04-24 19:28 UTC (permalink / raw To: gentoo-dev@lists.gentoo.org 2015-04-24 20:11 GMT+01:00 Maxim Koltsov <maksbotan@gentoo.org>: > This is temporal, until gcc gets needed support and that version makes its > way into ~. Then the flag won't be needed anymore, we'll just depend on new > enough gcc and enable C++14 mode by default. There is a problem with this. gcc has some bugs even in C++03 implementation (I have shown you the related bug the other day, can quote it here if anyone's interested), and for now I used C++14 flag to enable those code paths that depend on good enough standards support. The problem is that the other, kludgy code paths are incompatible with C++14 at all, so either LC is built in C++11 mode with C++11 plugins set, or in C++14 mode, but only using clang (or any other conforming compiler, but I'm not aware of anything like that). Effectively, even gcc 5.1 cannot build LC in C++14 mode. The same story will happen when C++17 gets released, so this should probably be settled once and for all. > I'm CCing LeechCraft author just in case. I'm on this list, no need to :) -- Georg Rudoy ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] RFC: c++14 global USE flag 2015-04-24 18:56 ` Ian Stakenvicius 2015-04-24 19:11 ` Maxim Koltsov @ 2015-04-25 14:09 ` Anthony G. Basile 2015-04-25 15:23 ` Peter Stuge 2015-04-25 15:47 ` [gentoo-dev] " Matthias Maier 1 sibling, 2 replies; 26+ messages in thread From: Anthony G. Basile @ 2015-04-25 14:09 UTC (permalink / raw To: gentoo-dev On 04/24/15 14:56, Ian Stakenvicius wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 24/04/15 02:42 PM, Ciaran McCreesh wrote: >> On Fri, 24 Apr 2015 21:12:32 +0300 Maxim Koltsov >> <maksbotan@gentoo.org> wrote: >>> Hello. My previous email was sent from the wrong address and it >>> seems it did not make it into the list. Sending again from the >>> right address... >>> >>> I'm introducing "c++14" use flag to every package in >>> app-leechcraft catherogy via leechcraft.eclass. I need to put USE >>> description somewhere. I propose / ask for permission to do it in >>> global use.desc. Putting this flag to every single metadata.xml >>> feels just wrong --- there are 72 of them now. >>> >>> Proposed description: "Build using C++ 14 standard" >>> >>> Looking forward for comments. >> This isn't going to be sustainable... What's the long-term plan >> for dealing with this? >> > Sounds like we need to go through the archives and revisit the > conversations about how to integrate c++11 , again.. Yes, this is going to be a perpetual problem in Gentoo. So right now, c++03 is stable and its abi is not going to change. c++11 is stable in gcc 5 and c++14 is experimental. Next will come c++17. The way gcc is dealing with this is that it is NOT bumping the soname so we can get libraries linking aginst libstdc++.so with the wrong abi and you get breakage. I wrote a blog entry [1] and opened a tracker [2]. That bug currently reads "[TRACKER] c++11 abi incompatibility" but we could expand it to include c++14 and beyond. I'm not sure how to solve this one, but a USE flag isn't going to work, at least not in the long run. Ref. [1] https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/ [2] https://bugs.gentoo.org/show_bug.cgi?id=542482 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iF4EAREIAAYFAlU6kfYACgkQ2ugaI38ACPCDuQEAhAv0boCkTU3RvT5d/fX3la7V > 8so0wqnPtHKI4fSqEwgA+wXmVlB14ykbTQ1VnrRR5WrEPRjMbm9V1MSXAA6MnC43 > =i/3U > -----END PGP SIGNATURE----- > -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] RFC: c++14 global USE flag 2015-04-25 14:09 ` Anthony G. Basile @ 2015-04-25 15:23 ` Peter Stuge 2015-04-25 15:57 ` [gentoo-dev] " Duncan 2015-04-25 15:47 ` [gentoo-dev] " Matthias Maier 1 sibling, 1 reply; 26+ messages in thread From: Peter Stuge @ 2015-04-25 15:23 UTC (permalink / raw To: gentoo-dev Anthony G. Basile wrote: > The way gcc is dealing with this is that it is NOT bumping the soname > so we can get libraries linking aginst libstdc++.so with the wrong abi > and you get breakage. .. > I'm not sure how to solve this one Is there any alternative to implementing the different sonames in Gentoo, if upstream doesn't want to do it? //Peter ^ permalink raw reply [flat|nested] 26+ messages in thread
* [gentoo-dev] Re: RFC: c++14 global USE flag 2015-04-25 15:23 ` Peter Stuge @ 2015-04-25 15:57 ` Duncan 2015-04-26 16:41 ` Diego Elio Pettenò 0 siblings, 1 reply; 26+ messages in thread From: Duncan @ 2015-04-25 15:57 UTC (permalink / raw To: gentoo-dev Peter Stuge posted on Sat, 25 Apr 2015 17:23:17 +0200 as excerpted: > Anthony G. Basile wrote: >> The way gcc is dealing with this is that it is NOT bumping the soname >> so we can get libraries linking aginst libstdc++.so with the wrong abi >> and you get breakage. > .. >> I'm not sure how to solve this one > > Is there any alternative to implementing the different sonames in > Gentoo, if upstream doesn't want to do it? How much of the toolchain is C++? Back in the day, gcc wasn't stable for C++, but the toolchain didn't use it, so standard procedure if you upgraded gcc was an emerge empty-tree @world (sometimes with an emerge empty-tree @system first). It was a bit of a pain, but gentooers accepted it as just how it was done, often delaying the gcc upgrade until they had time to do the full rebuild. And that was back when emerge empty-tree @world could typically take a couple days. What with faster machines these days, it might take a morning... So I really don't see it as a big problem, unless of course critical bits of the toolchain are C++. I guess paludis is, but that's its problem, and presumably they have workarounds. Just upgrade gcc and do the same empty-tree rebuild we all learned to accept as part of the program back when it took six or eight times as long... Of course, one thing that could make the process faster would be if C++ based packages were marked some way. Then have the PM hook that mark and only rebuild those packages, instead of the entire tree. Tho then you miss out on the improvements for C packages, etc, with those improvements presumably being why you'd upgrade in the first place, so for major gcc bumps, a full empty-tree rebuild has some merit, even if it weren't forced for C++ compatibility. -- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Re: RFC: c++14 global USE flag 2015-04-25 15:57 ` [gentoo-dev] " Duncan @ 2015-04-26 16:41 ` Diego Elio Pettenò 2015-04-27 3:21 ` Duncan 0 siblings, 1 reply; 26+ messages in thread From: Diego Elio Pettenò @ 2015-04-26 16:41 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 347 bytes --] On 25 April 2015 at 16:57, Duncan <1i5t5.duncan@cox.net> wrote: > Of course, one thing that could make the process faster would be if C++ > based packages were marked some way. revdep-rebuild --soname 'libstdc\+\+.so.*' should do the trick. Stuff that does not link the library (statically linked or using libsupc++) should not really matter. [-- Attachment #2: Type: text/html, Size: 691 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* [gentoo-dev] Re: RFC: c++14 global USE flag 2015-04-26 16:41 ` Diego Elio Pettenò @ 2015-04-27 3:21 ` Duncan 2015-04-28 20:07 ` Anthony G. Basile 0 siblings, 1 reply; 26+ messages in thread From: Duncan @ 2015-04-27 3:21 UTC (permalink / raw To: gentoo-dev Diego Elio Pettenò posted on Sun, 26 Apr 2015 17:41:04 +0100 as excerpted: > On 25 April 2015 at 16:57, Duncan <1i5t5.duncan@cox.net> wrote: > >> Of course, one thing that could make the process faster would be if C++ >> based packages were marked some way. > > > revdep-rebuild --soname 'libstdc\+\+.so.*' > > should do the trick. Stuff that does not link the library (statically > linked or using libsupc++) should not really matter. Thanks. Obvious in hindsight. =:^) Answering my own toolchain question then, for folks using portage as PM... [wow, portage takes /awhile/ evaluating order!]... Looks like dev-libs/gmp could be a problem. Back in the day we didn't have it to worry about, but coreutils uses it with USE=gmp, which I'd guess quite a few folks would have set for multi-processing support. But gmp appears to have a C and a C++ lib (libgmpxx.so.*), and coreutils wasn't in the above list on its own, so it would appear to be fine even if libgmpxx.so.* is broken, so... But obviously worth testing before each new gcc compatibility bump gets unmasked... Other than gmp, it looks like the old rules still apply just fine. Upgrade gcc, gcc-config switch to the new version, and emerge --emptytree @world, or at least revdep-rebuild --soname 'libstdc\+\+.so.*' as Diego points out. And as I already said, with modern hardware that takes... a morning... well, maybe a day if you've lots of packages installed or are on a slow (if modern) machine, not the two days plus it used to take when that was simply accepted as the way it was. So shouldn't be a big deal. Other than the usual upgrade bugs, then, the problem should be pretty well restricted to servantware which can't be rebuilt; more specifically, to C++ using servantware that can't be rebuilt. And that has always been a problem, which the people choosing to use it have chosen to live with, but which shouldn't hold back the free world that has chosen not to live in such bondage. For these people, what? Of course they used to get along when gcc's C++ was unstable before, so I guess they still can. Does libstdc++ get builtin as static? If so it shouldn't be an issue. If not... I guess they can preload libstdc++ from an older gcc. So maybe a news item explaining both the gcc upgrade procedure, and how to preload an old libstdc++, if they need to for binary-only servantware or whatever. -- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Re: RFC: c++14 global USE flag 2015-04-27 3:21 ` Duncan @ 2015-04-28 20:07 ` Anthony G. Basile 2015-04-28 21:52 ` Mike Gilbert 0 siblings, 1 reply; 26+ messages in thread From: Anthony G. Basile @ 2015-04-28 20:07 UTC (permalink / raw To: gentoo-dev On 04/26/15 23:21, Duncan wrote: > Diego Elio Pettenò posted on Sun, 26 Apr 2015 17:41:04 +0100 as excerpted: > >> On 25 April 2015 at 16:57, Duncan <1i5t5.duncan@cox.net> wrote: >> >>> Of course, one thing that could make the process faster would be if C++ >>> based packages were marked some way. >> >> revdep-rebuild --soname 'libstdc\+\+.so.*' >> >> should do the trick. Stuff that does not link the library (statically >> linked or using libsupc++) should not really matter. > Thanks. Obvious in hindsight. =:^) > just saw this. This works unless you have two versions of gcc installed. The c++11 abi emitted by gcc-4.7 and 4.8 are different and since you link against the latest version (see the ordering of directories in /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf), building with the earlier gcc can cause breakage. We may not want to support such a situation but I'd like to. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Re: RFC: c++14 global USE flag 2015-04-28 20:07 ` Anthony G. Basile @ 2015-04-28 21:52 ` Mike Gilbert 2015-04-29 11:27 ` Anthony G. Basile 0 siblings, 1 reply; 26+ messages in thread From: Mike Gilbert @ 2015-04-28 21:52 UTC (permalink / raw To: Gentoo Dev On Tue, Apr 28, 2015 at 4:07 PM, Anthony G. Basile <blueness@gentoo.org> wrote: > On 04/26/15 23:21, Duncan wrote: >> >> Diego Elio Pettenò posted on Sun, 26 Apr 2015 17:41:04 +0100 as excerpted: >> >>> On 25 April 2015 at 16:57, Duncan <1i5t5.duncan@cox.net> wrote: >>> >>>> Of course, one thing that could make the process faster would be if C++ >>>> based packages were marked some way. >>> >>> >>> revdep-rebuild --soname 'libstdc\+\+.so.*' >>> >>> should do the trick. Stuff that does not link the library (statically >>> linked or using libsupc++) should not really matter. >> >> Thanks. Obvious in hindsight. =:^) >> > > just saw this. This works unless you have two versions of gcc installed. > The c++11 abi emitted by gcc-4.7 and 4.8 are different and since you link > against the latest version (see the ordering of directories in > /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf), building with the earlier > gcc can cause breakage. We may not want to support such a situation but I'd > like to. As I understand it, a given version of gcc links objects against its own version of libstdc++, but the "latest" version of libstdc++ is loaded by ld.so at runtime. Maybe that's what you meant, but I wanted to clarify that. And if I am wrong on that, please correct me. ^_^ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Re: RFC: c++14 global USE flag 2015-04-28 21:52 ` Mike Gilbert @ 2015-04-29 11:27 ` Anthony G. Basile 2015-05-02 21:11 ` Maxim Koltsov 0 siblings, 1 reply; 26+ messages in thread From: Anthony G. Basile @ 2015-04-29 11:27 UTC (permalink / raw To: gentoo-dev On 04/28/15 17:52, Mike Gilbert wrote: > On Tue, Apr 28, 2015 at 4:07 PM, Anthony G. Basile <blueness@gentoo.org> wrote: >> On 04/26/15 23:21, Duncan wrote: >>> Diego Elio Pettenò posted on Sun, 26 Apr 2015 17:41:04 +0100 as excerpted: >>> >>>> On 25 April 2015 at 16:57, Duncan <1i5t5.duncan@cox.net> wrote: >>>> >>>>> Of course, one thing that could make the process faster would be if C++ >>>>> based packages were marked some way. >>>> >>>> revdep-rebuild --soname 'libstdc\+\+.so.*' >>>> >>>> should do the trick. Stuff that does not link the library (statically >>>> linked or using libsupc++) should not really matter. >>> Thanks. Obvious in hindsight. =:^) >>> >> just saw this. This works unless you have two versions of gcc installed. >> The c++11 abi emitted by gcc-4.7 and 4.8 are different and since you link >> against the latest version (see the ordering of directories in >> /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf), building with the earlier >> gcc can cause breakage. We may not want to support such a situation but I'd >> like to. > As I understand it, a given version of gcc links objects against its > own version of libstdc++, but the "latest" version of libstdc++ is > loaded by ld.so at runtime. > > Maybe that's what you meant, but I wanted to clarify that. And if I am > wrong on that, please correct me. ^_^ > Yes. So you could, for example, fix this by setting the correct rpath at link time so the correct library gets loaded at runtime. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Re: RFC: c++14 global USE flag 2015-04-29 11:27 ` Anthony G. Basile @ 2015-05-02 21:11 ` Maxim Koltsov 2015-05-02 21:17 ` Kent Fredric 0 siblings, 1 reply; 26+ messages in thread From: Maxim Koltsov @ 2015-05-02 21:11 UTC (permalink / raw To: gentoo-dev@lists.gentoo.org [-- Attachment #1: Type: text/plain, Size: 2692 bytes --] 2015-04-29 14:27 GMT+03:00 Anthony G. Basile <blueness@gentoo.org>: > On 04/28/15 17:52, Mike Gilbert wrote: > >> On Tue, Apr 28, 2015 at 4:07 PM, Anthony G. Basile <blueness@gentoo.org> >> wrote: >> >>> On 04/26/15 23:21, Duncan wrote: >>> >>>> Diego Elio Pettenò posted on Sun, 26 Apr 2015 17:41:04 +0100 as >>>> excerpted: >>>> >>>> On 25 April 2015 at 16:57, Duncan <1i5t5.duncan@cox.net> wrote: >>>>> >>>>> Of course, one thing that could make the process faster would be if >>>>>> C++ >>>>>> based packages were marked some way. >>>>>> >>>>> >>>>> revdep-rebuild --soname 'libstdc\+\+.so.*' >>>>> >>>>> should do the trick. Stuff that does not link the library (statically >>>>> linked or using libsupc++) should not really matter. >>>>> >>>> Thanks. Obvious in hindsight. =:^) >>>> >>>> just saw this. This works unless you have two versions of gcc >>> installed. >>> The c++11 abi emitted by gcc-4.7 and 4.8 are different and since you link >>> against the latest version (see the ordering of directories in >>> /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf), building with the >>> earlier >>> gcc can cause breakage. We may not want to support such a situation but >>> I'd >>> like to. >>> >> As I understand it, a given version of gcc links objects against its >> own version of libstdc++, but the "latest" version of libstdc++ is >> loaded by ld.so at runtime. >> >> Maybe that's what you meant, but I wanted to clarify that. And if I am >> wrong on that, please correct me. ^_^ >> >> > Yes. So you could, for example, fix this by setting the correct rpath at > link time so the correct library gets loaded at runtime. I fear this discussion is going in a slightly wrong direction. I'm not going to make any global Gentoo changes, I just need to add support for C++14 mode in a bunch of packages I maintain, and for that, I need to decide on a place to store USE descriptions. If I won't get good options, I'll just go and add this description to every of ~70 metadata's. Please consider the patch I'm going to apply to our eclass: https://bpaste.net/show/39ec6f4760f4 This is intended as an experimental feature, not as a globally supported configuration for every package in Gentoo. This is needed because already now LeechCraft has some functionality that is implemented in C++14 and won't be available otherwise. Please give your opinion on where to put this USE desc, that's all I want :) > -- > Anthony G. Basile, Ph.D. > Gentoo Linux Developer [Hardened] > E-Mail : blueness@gentoo.org > GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA > GnuPG ID : F52D4BBA > > [-- Attachment #2: Type: text/html, Size: 4545 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Re: RFC: c++14 global USE flag 2015-05-02 21:11 ` Maxim Koltsov @ 2015-05-02 21:17 ` Kent Fredric 2015-05-02 22:18 ` Georg Rudoy 0 siblings, 1 reply; 26+ messages in thread From: Kent Fredric @ 2015-05-02 21:17 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 408 bytes --] On 3 May 2015 at 09:11, Maxim Koltsov <maksbotan@gentoo.org> wrote: > LeechCraft has some functionality that is implemented in C++14 and won't > be available otherwise. > Can you clarify the nature of that functionality? Shouldn't the USE flag be thus in terms of what that functionality is, not in terms of the dependency required to provide it? -- Kent *KENTNL* - https://metacpan.org/author/KENTNL [-- Attachment #2: Type: text/html, Size: 1121 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Re: RFC: c++14 global USE flag 2015-05-02 21:17 ` Kent Fredric @ 2015-05-02 22:18 ` Georg Rudoy 2015-05-02 22:30 ` Kent Fredric 0 siblings, 1 reply; 26+ messages in thread From: Georg Rudoy @ 2015-05-02 22:18 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1522 bytes --] 2015-05-03 0:17 GMT+03:00 Kent Fredric <kentfredric@gmail.com>: > > On 3 May 2015 at 09:11, Maxim Koltsov <maksbotan@gentoo.org> wrote: > >> LeechCraft has some functionality that is implemented in C++14 and won't >> be available otherwise. >> > > Can you clarify the nature of that functionality? > The Tox support module and email client module (the latter isn't in tree yet, but a good example anyway) both rely on relaxed constexpr from C++14. In some of the newer code I rely on automatic return type deduction and generic lambdas, for example, or some changes in STL. Thus, it's safer to say that basically all new modules that are written (and would be written) since ~January 2015 would require C++14 as a baseline language. Moreover, C++14 allows writing more efficient code (without extra levels of indirection induced by std::function required if one is to specify the return type of a function returning a lambda, for example) in some places. > Shouldn't the USE flag be thus in terms of what that functionality is, not > in terms of the dependency required to provide it? > Since the most general criteria for the functionality is "whether C++14 compiler is available", "c++14" or something like that seems the best fit for the USE flag name. We have "idn" or "gnutls" or "python" etc USE flags after all, not "support_international_names_in_blah" or "allow_secure_news_fetching_in_foo" or "build_scripting_support_for_baz". Or I just didn't get you here, sorry me in this case :) -- Georg Rudoy [-- Attachment #2: Type: text/html, Size: 2645 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Re: RFC: c++14 global USE flag 2015-05-02 22:18 ` Georg Rudoy @ 2015-05-02 22:30 ` Kent Fredric 2015-05-03 10:19 ` Maxim Koltsov 2015-05-03 14:04 ` Georg Rudoy 0 siblings, 2 replies; 26+ messages in thread From: Kent Fredric @ 2015-05-02 22:30 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1705 bytes --] On 3 May 2015 at 10:18, Georg Rudoy <0xd34df00d@gmail.com> wrote: > We have "idn" or "gnutls" or "python" etc USE flags after all, not > "support_international_names_in_blah" or > "allow_secure_news_fetching_in_foo" or "build_scripting_support_for_baz". > > Or I just didn't get you here, sorry me in this case :) > The difference is semantics. "idn" *is* saying "Support for international names" ( not in, but _for_ ) and python very often *is* saying "Support for python" ( not in, but _for_ ) That's "for", not "by". For support *by* python, an explicit python use-flag is not entirely necessary. Just like you presently don't have ( and we don't have ) a "USE=c" flag just to make sure you have a C compiler. What does it matter to a user that its in C++14 ? It doesn't. And end user is more concerned with "what does this do for me". If for instance a specific user visible tool became magically available with "USE=C++14", and that was the only tool that became visible as a result, that would, for example, be really silly. If a useflag doesn't tell me what it does for me, then what impetus is there for me to toggle it? For instance, Seamonkey doesn't have a USE=perl flag. Nor should it have one. It does however have a USE=crypt flag, which utilizes perl as part of its work. ( And its only a compile time dependency also ). But you seem to want USE=perl # turn on crypt features Which is inherently backwards. There is still places where that makes a degree of sense, but in cases like "give new user facing features features" an ambiguous "C++" toggle is not going to be communicating intent in an appropriate manner. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL [-- Attachment #2: Type: text/html, Size: 3073 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Re: RFC: c++14 global USE flag 2015-05-02 22:30 ` Kent Fredric @ 2015-05-03 10:19 ` Maxim Koltsov 2015-05-03 10:51 ` Duncan 2015-05-03 14:08 ` Georg Rudoy 2015-05-03 14:04 ` Georg Rudoy 1 sibling, 2 replies; 26+ messages in thread From: Maxim Koltsov @ 2015-05-03 10:19 UTC (permalink / raw To: gentoo-dev@lists.gentoo.org [-- Attachment #1: Type: text/plain, Size: 2155 bytes --] 2015-05-03 1:30 GMT+03:00 Kent Fredric <kentfredric@gmail.com>: > > On 3 May 2015 at 10:18, Georg Rudoy <0xd34df00d@gmail.com> wrote: > >> We have "idn" or "gnutls" or "python" etc USE flags after all, not >> "support_international_names_in_blah" or >> "allow_secure_news_fetching_in_foo" or "build_scripting_support_for_baz". >> >> Or I just didn't get you here, sorry me in this case :) >> > > > The difference is semantics. > > "idn" *is* saying "Support for international names" ( not in, but _for_ ) > > and python very often *is* saying "Support for python" ( not in, but _for_ > ) > > That's "for", not "by". For support *by* python, an explicit python > use-flag is not entirely necessary. > > Just like you presently don't have ( and we don't have ) a "USE=c" flag > just to make sure you have a C compiler. > > What does it matter to a user that its in C++14 ? It doesn't. > > And end user is more concerned with "what does this do for me". > > If for instance a specific user visible tool became magically available > with "USE=C++14", and that was the only tool that became visible as a > result, that would, for example, be really silly. > > If a useflag doesn't tell me what it does for me, then what impetus is > there for me to toggle it? > > For instance, Seamonkey doesn't have a USE=perl flag. Nor should it have > one. > > It does however have a USE=crypt flag, which utilizes perl as part of its > work. ( And its only a compile time dependency also ). > > But you seem to want USE=perl # turn on crypt features > > Which is inherently backwards. > > There is still places where that makes a degree of sense, but in cases > like "give new user facing features features" an ambiguous "C++" toggle is > not going to be communicating intent in an appropriate manner. > > Well, I can see your point. But I don't see any reasonable alternative --- this functionality can't be generalized by any name, except "c++14" --- that's only thing in common. Moreover, this is (I hope) a _temporal_ solution, until there's a gcc with needed level of support. And of course we can put a message about this flag in eclass and/or on LeechCraft site. [-- Attachment #2: Type: text/html, Size: 3533 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* [gentoo-dev] Re: RFC: c++14 global USE flag 2015-05-03 10:19 ` Maxim Koltsov @ 2015-05-03 10:51 ` Duncan 2015-05-03 14:13 ` Georg Rudoy 2015-05-03 14:08 ` Georg Rudoy 1 sibling, 1 reply; 26+ messages in thread From: Duncan @ 2015-05-03 10:51 UTC (permalink / raw To: gentoo-dev Maxim Koltsov posted on Sun, 03 May 2015 13:19:18 +0300 as excerpted: > this functionality can't be generalized by any name, except "c++14" --- > that's only thing in common. Moreover, this is (I hope) a _temporal_ > solution, until there's a gcc with needed level of support. And of > course we can put a message about this flag in eclass and/or on > LeechCraft site. What about a somewhat more generic flag such as newcode? Like the bindist or minimal flags, this could be global, but with local descriptions very strongly recommended. Similarly, like minimal, setting it globally would be strongly discouraged. In this case, the newcode local description would be something like: C++14 related: gcc doesn't support yet, requires clang ... with an appropriate use-conditional dep. The newcode flag would however be generic enough that it could be reused for C++17, etc, as well, and could obviously be phased out for any particular package once its specific newcode dependencies are met in stable -- in this case, when a supporting gcc stabilizes. newcode would even be generic enough to be used for say qt6 when the time comes, if it turns out to be stuck in the qt overlay for quite some time, as was qt5, for the longest time, and the good bit is, generic meaning, that USE=newcode requires a dep that's still generally problematic or might be considered excessive to get, for optional functionality that may or may not be considered worth it, should be pretty obvious. Making that meaning even more obvious would be the fact that the flag would likely be packageuse-masked for many users for much of the the time. That could for instance allow packages using it in-tree, before the dep it pulls in is itself in-tree, while still making it possible to unmask, for users who either already have the required overlay active, or who don't have it active ATM, but are willing to activate it to get the features it toggles. -- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Re: RFC: c++14 global USE flag 2015-05-03 10:51 ` Duncan @ 2015-05-03 14:13 ` Georg Rudoy 2015-05-04 4:36 ` Duncan 0 siblings, 1 reply; 26+ messages in thread From: Georg Rudoy @ 2015-05-03 14:13 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2681 bytes --] 2015-05-03 13:51 GMT+03:00 Duncan <1i5t5.duncan@cox.net>: > What about a somewhat more generic flag such as newcode? Like the bindist > or minimal flags, this could be global, but with local descriptions very > strongly recommended. Similarly, like minimal, setting it globally would > be strongly discouraged. > > In this case, the newcode local description would be something like: > > C++14 related: gcc doesn't support yet, requires clang > > ... with an appropriate use-conditional dep. > > The newcode flag would however be generic enough that it could be reused > for C++17, etc, as well, and could obviously be phased out for any > particular package once its specific newcode dependencies are met in > stable -- in this case, when a supporting gcc stabilizes. > Nice idea, thanks! There are a couple of corner cases though. > newcode would even be generic enough to be used for say qt6 when the time > comes, if it turns out to be stuck in the qt overlay for quite some time, > as was qt5, for the longest time, What if a package would support (optional) builds with C++17-related features and (optional) builds with say Qt6, and these could be toggled independently? Does that imply having something like newcode_cpp17 and newcode_qt4 on per-package basis? > and the good bit is, generic meaning, > that USE=newcode requires a dep that's still generally problematic or > might be considered excessive to get, for optional functionality that may > or may not be considered worth it, should be pretty obvious. > Does that imply that merely pulling clang for builds is not a newcode-concern then, and, back to the original topic, in case of leechcraft C++14 can be enabled unconditionally, again with unconditional pulling of clang? That's probably a way to go, but feels like not Gentoo-way enough (just removing an option). > Making that meaning even more obvious would be the fact that the flag > would likely be packageuse-masked for many users for much of the the > time. That could for instance allow packages using it in-tree, before > the dep it pulls in is itself in-tree, while still making it possible to > unmask, for users who either already have the required overlay active, or > who don't have it active ATM, but are willing to activate it to get the > features it toggles. > Depending on the answer to the previous question, if all the deps are in-tree, then there is no need in masking the useflag. It could be unmasked on the per-package basis again, I guess? Then there is a question of the default (globally unmasked and per-package masks vs globally masked and per-package unmasks), but that's a relatively minor one. -- Georg Rudoy [-- Attachment #2: Type: text/html, Size: 3642 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* [gentoo-dev] Re: RFC: c++14 global USE flag 2015-05-03 14:13 ` Georg Rudoy @ 2015-05-04 4:36 ` Duncan 0 siblings, 0 replies; 26+ messages in thread From: Duncan @ 2015-05-04 4:36 UTC (permalink / raw To: gentoo-dev Georg Rudoy posted on Sun, 03 May 2015 17:13:49 +0300 as excerpted: > 2015-05-03 13:51 GMT+03:00 Duncan <1i5t5.duncan@cox.net>: > >> What about a somewhat more generic flag such as newcode? > Nice idea, thanks! There are a couple of corner cases though. > >> newcode would even be generic enough to be used for say qt6 when the >> time comes, if it turns out to be stuck in the qt overlay for quite >> some time, as was qt5, for the longest time, > > > What if a package would support (optional) builds with C++17-related > features and (optional) builds with say Qt6, and these could be toggled > independently? Does that imply having something like newcode_cpp17 and > newcode_qt4 on per-package basis? Hmm... indeed. That case would lend itself to a USE_EXPAND, with newcode the name of the use-expand var, and individual values for this var of qt6, cpp17, etc. I hadn't thought of that until you mentioned it, but it's the logical extension. >> and the good bit is, generic meaning, >> that USE=newcode requires a dep that's still generally problematic or >> might be considered excessive to get, for optional functionality that >> may or may not be considered worth it, should be pretty obvious. >> >> > Does that imply that merely pulling clang for builds is not a > newcode-concern then, and, back to the original topic, in case of > leechcraft C++14 can be enabled unconditionally, again with > unconditional pulling of clang? > > That's probably a way to go, but feels like not Gentoo-way enough (just > removing an option). I think that depends on the package and package maintainer, as much as anything. The real question for the maintainer, then, becomes one of "If it comes down to it, would I rather that a potential user reject the package entirely due to this dependency they consider unacceptable, in ordered to save the hassle of maintaining the optional dependency code, or would I rather give them the choice and have to maintain that additional optional dependency code?" Leachcraft is a very nice little niche, but it's a niche, that already both isn't particularly likely to be discovered, and if discovered, may well not be of interest. Making the clang dep optional sounds like it'll be significantly more work, the cost on the one side, while the cost on the other is potentially limiting the already niche interest leachcraft to an even smaller niche, and giving up on those people who were thinking about installing it just to try out, but see that extra dep and decide it's not worth their hassle. And of course it works the other way too. There may be people who already know and use leachcraft, but can barely justify it already, who might decide that additional dependency is simply one dependency too far. I found here, and I expect many experienced gentooers who have also used binary distros will agree, for packages you use all the time, the build- cost difference between a binary distro and a from-source distro like gentoo is trivial, the use of the package far outweighs it anyway. But what about that package you only use once in awhile? I guess CD/DVD burning software might be a good example for many. Maybe they use it once or twice a year, maybe every two years. Yeah, it's useful, once in awhile, and on a binary distro, no problem, just install it. But on a from source distro like gentoo, once you find yourself repeatedly upgrading it between uses, so you're not even using the package once before it's upgraded again, at some point you ask yourself why you even keep it installed. If you decide you want to burn a DVD, you can merge it then, do the burn, and unmerge, without it ever hitting the world file, and with your next depclean removing it if you forget. And once you get to that point, additional exclusive deps start adding up pretty quickly, and before you know it you're looking for an alternative that doesn't pull in all those extra deps, so it's just the quick build/ merge/burn/unmerge that fits the once every couple years use-case. So again, maintainer viewpoint, for something already niche, is it worth the extra work to avoid it being even /more/ niche due to the uncommon mandatory dep, or is it a question of of it's niche already, and is hardly worth the work already, so just do what's simplest and the people that want it will be willing to jump thru the hoops and those that can't be bothered, aren't worth the extra work to worry about? That's a question only the maintainer can answer, particularly for niche packages that chances are would end up without a maintainer and eventually tree-cleaned, if the current maintainer quits. (For more mainstream packages or package-groups, say kde, with an extremely active overlay and a whole crew of folks both devs and advanced user volunteers helping out, it's a bit of a different story. Tho the general principle still applies, because in practice it's the only way that works. Refer to the kde4 semantic-desktop experience for example -- semantic-desktop was removed as an option and made required in the overlay and ~arch, because none of the maintainers were sufficiently interested in doing the extra work to support the option. Fortunately one of the kde devs decided they wanted that feature option, I believe before it was removed from stable, so it survived at least thru kde4 (I'm actually not sure what semantic-desktop status is on kde5/frameworks, as kwin5 doesn't seem to like my radeon kernel/mesa native graphics and goes into a crash/respawn loop every time I try it, so I'm still on kde4, for now). But as a pre-release and even kde-live-9999 package user, I was having to maintain the semantic-desktop opt-out version patches for my own overlay, for a time, and as it hit ~arch and almost hit stable, I and other users came very close to creating a user-maintained kde-semantic- free overlay, using the the user-maintained kde-sunset overlay as our precedent.) >> Making that meaning even more obvious would be the fact that the flag >> would likely be packageuse-masked for many users for much of the the >> time. That could for instance allow packages using it in-tree, before >> the dep it pulls in is itself in-tree, while still making it possible >> to unmask, for users who either already have the required overlay >> active, or who don't have it active ATM, but are willing to activate it >> to get the features it toggles. >> >> > Depending on the answer to the previous question, if all the deps are > in-tree, then there is no need in masking the useflag. It could be > unmasked on the per-package basis again, I guess? Then there is a > question of the default (globally unmasked and per-package masks vs > globally masked and per-package unmasks), but that's a relatively minor > one. Well, technically, in-tree and stable. But I was abbreviating that to in- tree, so you can too, as long as the technical detail is understood. And yes, that's specifically what per-package use-masks are all about, to allow packages to stabilize before all their optional deps are stabilized, by per-package use-masking the flags that pull in those deps. (Note that I'm deliberately blurring the detail here, too, as I read the discussion about per-package masks, how to unmask them when needed, etc, when it occurred, but I've never had to actually unmask from that here, and I'm user-side so haven't had to worry about the dev side either, and thus haven't had to actually crystallize the detail in practice here, and thus read but haven't retained it. But I know about it and can look up the details if I need them, which is enough...) -- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Re: RFC: c++14 global USE flag 2015-05-03 10:19 ` Maxim Koltsov 2015-05-03 10:51 ` Duncan @ 2015-05-03 14:08 ` Georg Rudoy 1 sibling, 0 replies; 26+ messages in thread From: Georg Rudoy @ 2015-05-03 14:08 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 760 bytes --] 2015-05-03 13:19 GMT+03:00 Maxim Koltsov <maksbotan@gentoo.org>: > Well, I can see your point. But I don't see any reasonable alternative --- > this functionality can't be generalized by any name, except "c++14" --- > that's only thing in common. > Yes, exactly. > Moreover, this is (I hope) a _temporal_ solution, until there's a gcc with > needed level of support. > I have increasing concerns about that. The relevant bugreport ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60177 ) is more than a year old, and still no feedback on it from gcc guys. Moreover, this bug is hardly related to C++11/14 — it's pure 03. I could live with some kludges in C++11, but they became incompatible with some of C++14. -- Georg Rudoy [-- Attachment #2: Type: text/html, Size: 1662 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Re: RFC: c++14 global USE flag 2015-05-02 22:30 ` Kent Fredric 2015-05-03 10:19 ` Maxim Koltsov @ 2015-05-03 14:04 ` Georg Rudoy 2015-05-03 19:07 ` Kent Fredric 2015-05-04 3:29 ` Duncan 1 sibling, 2 replies; 26+ messages in thread From: Georg Rudoy @ 2015-05-03 14:04 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1324 bytes --] 2015-05-03 1:30 GMT+03:00 Kent Fredric <kentfredric@gmail.com>: > and python very often *is* saying "Support for python" ( not in, but _for_ > ) > Why should the user care if python is supported? What does python support per se offer to the user? I would argue that what's important are the features exposed via Python stuff (unless the user theyself is expected to write some Python code, of course). Same logic applies for C++14, IMHO. > What does it matter to a user that its in C++14 ? It doesn't. > And end user is more concerned with "what does this do for me". > > If a useflag doesn't tell me what it does for me, then what impetus is > there for me to toggle it? > The consequences do matter, like pulling and building llvm/clang, if not present already. Toggle it if you're ready to deal with the consequences (having clang in your system, particularly). Speaking of llvm, media-libs/mesa has "llvm" use flag. Why should user care if it's llvm or whatever? > For instance, Seamonkey doesn't have a USE=perl flag. Nor should it have > one. > Nice example with USE=perl, thanks! git has that, for instance. Without that, `git add -i` won't work, but I still have USE=perl, not USE=add_interactive and possibly a bunch of other features depending on Perl that would pull it when enabled. -- Georg Rudoy [-- Attachment #2: Type: text/html, Size: 2777 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Re: RFC: c++14 global USE flag 2015-05-03 14:04 ` Georg Rudoy @ 2015-05-03 19:07 ` Kent Fredric 2015-05-04 3:29 ` Duncan 1 sibling, 0 replies; 26+ messages in thread From: Kent Fredric @ 2015-05-03 19:07 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2747 bytes --] On 4 May 2015 at 02:04, Georg Rudoy <0xd34df00d@gmail.com> wrote: > Why should the user care if python is supported? What does python support > per se offer to the user? I would argue that what's important are the > features exposed via Python stuff (unless the user theyself is expected to > write some Python code, of course). > > By support "for" python, I mean "This flag exposes a new feature to userspace". For instance, it may install python modules that a user may desire to consume in the course of their programming. Thus, they are not likely to want that flag on, unless they are doing exactly that. Or a dependant may require those modules to be available, and may depend on that package with the flag enabled to access those libraries. Thus, the "feature" that the flag exposes is "Support for people or code who explicitly need something python related in using it". Same logic applies for C++14, IMHO. > The same logic here would be: - People are developing their own code for leechcraft that needs leechcraft to be compiled differently for them to do that, and that flag changes how leechcraft is compiled so that they can do that - Some dependent is in the above situation, and wishes to be able to force leechcraft to be compiled so that it may work. Simply put: "Compiled using C++14" is not a "feature" unless somebody somewhere explicitly needs C++14 compilation. > >> What does it matter to a user that its in C++14 ? It doesn't. >> > And end user is more concerned with "what does this do for me". >> >> If a useflag doesn't tell me what it does for me, then what impetus is >> there for me to toggle it? >> > > The consequences do matter, like pulling and building llvm/clang, if not > present already. Toggle it if you're ready to deal with the consequences > (having clang in your system, particularly). > > Speaking of llvm, media-libs/mesa has "llvm" use flag. Why should user > care if it's llvm or whatever? > > > For instance, Seamonkey doesn't have a USE=perl flag. Nor should it have >> one. >> > > Nice example with USE=perl, thanks! git has that, for instance. Without > that, `git add -i` won't work, but I still have USE=perl, not > USE=add_interactive and possibly a bunch of other features depending on > Perl that would pull it when enabled. > Right, its not a black/white thing, and I would argue that flag on git is poorly named. But the general pattern is its recommended to express useflags to users in terms of "things I can see will be useful to me", thus, if you can make a more purpose-specific flag, it is wise to do so. Its not that doing it that way is "wrong" per say. Just a sub-optimal choice that requires more thinking. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL [-- Attachment #2: Type: text/html, Size: 5225 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* [gentoo-dev] Re: RFC: c++14 global USE flag 2015-05-03 14:04 ` Georg Rudoy 2015-05-03 19:07 ` Kent Fredric @ 2015-05-04 3:29 ` Duncan 1 sibling, 0 replies; 26+ messages in thread From: Duncan @ 2015-05-04 3:29 UTC (permalink / raw To: gentoo-dev Georg Rudoy posted on Sun, 03 May 2015 17:04:54 +0300 as excerpted: > Speaking of llvm, media-libs/mesa has "llvm" use flag. Why should user > care if it's llvm or whatever? The local use-description tells the store there: "Enamble LLVM backend for Gallium3D" In this case, LLVM is the feature, and it is billed as such by upstream. Gallium3D can optionally use LLVM to compile shading-language programs to run on the programmable shaders. An alternative USE flag name would be shading-vm, or similar, but because upstream actually "sells" the feature as an LLVM shading language backend, LLVM really is as much the feature as would be shading-vm or shading-compiler or some such, except because it /does/ pull in an LLVM that people might not otherwise need on their machine, the llvm flag is actually more descriptive, since it says what it pulls in as a dep, as well. Of course, if there were multiple choices, then it could either be a generic shading-compiler flag, with flags for each compiler as well, or it could be setup as a USE_EXPAND list, sl_llvm, sl_gcc, sl_amd, sl_intel... -- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] RFC: c++14 global USE flag 2015-04-25 14:09 ` Anthony G. Basile 2015-04-25 15:23 ` Peter Stuge @ 2015-04-25 15:47 ` Matthias Maier 1 sibling, 0 replies; 26+ messages in thread From: Matthias Maier @ 2015-04-25 15:47 UTC (permalink / raw To: gentoo-dev gcc upstream has at least unified the C++98(03) and C++11 abis in gcc-5 [1] and declared the C++11 abi stable. This could resolve [2] in the "near" future.. Best, Matthias [1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html [2] https://bugs.gentoo.org/show_bug.cgi?id=542482 ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2015-05-04 4:36 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-04-24 18:12 [gentoo-dev] RFC: c++14 global USE flag Maxim Koltsov 2015-04-24 18:42 ` Ciaran McCreesh 2015-04-24 18:56 ` Ian Stakenvicius 2015-04-24 19:11 ` Maxim Koltsov 2015-04-24 19:28 ` Georg Rudoy 2015-04-25 14:09 ` Anthony G. Basile 2015-04-25 15:23 ` Peter Stuge 2015-04-25 15:57 ` [gentoo-dev] " Duncan 2015-04-26 16:41 ` Diego Elio Pettenò 2015-04-27 3:21 ` Duncan 2015-04-28 20:07 ` Anthony G. Basile 2015-04-28 21:52 ` Mike Gilbert 2015-04-29 11:27 ` Anthony G. Basile 2015-05-02 21:11 ` Maxim Koltsov 2015-05-02 21:17 ` Kent Fredric 2015-05-02 22:18 ` Georg Rudoy 2015-05-02 22:30 ` Kent Fredric 2015-05-03 10:19 ` Maxim Koltsov 2015-05-03 10:51 ` Duncan 2015-05-03 14:13 ` Georg Rudoy 2015-05-04 4:36 ` Duncan 2015-05-03 14:08 ` Georg Rudoy 2015-05-03 14:04 ` Georg Rudoy 2015-05-03 19:07 ` Kent Fredric 2015-05-04 3:29 ` Duncan 2015-04-25 15:47 ` [gentoo-dev] " Matthias Maier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox