[gentoo-dev] RFC: c++14 global USE flag

[gentoo-dev] RFC: c++14 global USE flag

[Maxim Koltsov]

[-- 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 --]

Re: [gentoo-dev] RFC: c++14 global USE flag

[Ciaran McCreesh]

[-- 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 --]

Re: [gentoo-dev] RFC: c++14 global USE flag

[Ian Stakenvicius]

-----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-----

Re: [gentoo-dev] RFC: c++14 global USE flag

[Maxim Koltsov]

[-- 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 --]

Re: [gentoo-dev] RFC: c++14 global USE flag

[Georg Rudoy]

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

Re: [gentoo-dev] RFC: c++14 global USE flag

[Anthony G. Basile]

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

Re: [gentoo-dev] RFC: c++14 global USE flag

[Peter Stuge]

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

Re: [gentoo-dev] RFC: c++14 global USE flag

[Matthias Maier]

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

[gentoo-dev] Re: RFC: c++14 global USE flag

[Duncan]

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

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Diego Elio Pettenò]

[-- 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 --]

[gentoo-dev] Re: RFC: c++14 global USE flag

[Duncan]

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

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Anthony G. Basile]

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

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Mike Gilbert]

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. ^_^

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Anthony G. Basile]

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

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Maxim Koltsov]

[-- 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 --]

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Kent Fredric]

[-- 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 --]

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Georg Rudoy]

[-- 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 --]

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Kent Fredric]

[-- 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 --]

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Maxim Koltsov]

[-- 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 --]

[gentoo-dev] Re: RFC: c++14 global USE flag

[Duncan]

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

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Georg Rudoy]

[-- 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 --]

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Georg Rudoy]

[-- 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 --]

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Georg Rudoy]

[-- 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 --]

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Kent Fredric]

[-- 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 --]

[gentoo-dev] Re: RFC: c++14 global USE flag

[Duncan]

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

[gentoo-dev] Re: RFC: c++14 global USE flag

[Duncan]

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