Re: [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions

[Austin English]

On 07/05/2016 12:00 AM, Michał Górny wrote:
> On Mon, 4 Jul 2016 19:16:55 -0500
> Austin English <wizardedit@g.o> wrote:
>
>> On 07/01/2016 03:02 PM, Michał Górny wrote:
>>> On Mon, 27 Jun 2016 17:04:41 -0500
>>> Austin English <wizardedit@g.o> wrote:
>>>
>>>> From ec0be3d1a808ea0c5bdd081a4bb935f86bf78d44 Mon Sep 17 00:00:00 2001
>>>> From: Austin English <wizardedit@g.o>
>>>> Date: Mon, 27 Jun 2016 16:58:07 -0500
>>>> Subject: [PATCH 2/2] eclass/toolchain-funcs: add clang version functions
>>>
>>> Why do you even ask for review if you can't wait till the weekend
>>> before committing?
>>
>> There's no set time limit that I could find anywhere. I checked with my
>> mentor first, who said a few days was enough (as there were no comments
>> by anyone).
>>
>>> I've already told you twice that I'm opposed to adding version querying
>>> functions for clang, especially for the use case you proposed. You
>>> should check for features, and not keep a huge list of supported gcc,
>>> clang, pathcc, icc... versions. With every random compiler pretending
>>> to be a random version of every other compiler.
>>
>> I did not use in the original intended case, however I think that these
>> helpers are still useful. Why do we allow gcc version checks then?
>
> Because the ebuilds are full of that nonsense, and developers using
> them don't help you remove it.

Ack.

> If we committed every single thing someone thought someone else might
> find useful one day, the eclass would be huge hogs full of useless code
> that is only used because someone noticed the function and suddenly
> came to conclusion it's a good idea to use it because someone added it.
>
> Now let's add 4 additional functions for every single compiler that
> someone may decide to support one day. I'm even strongly opposed to
> adding functions that are used only theoretically.
>
>> There's no deprecated comment for these functions. By that logic, you
>> should not have added tc-is-{gcc,clang}, 2 weeks ago in
>> 6984a5b149a215dd96a9759d3d1f251354faf38f. You should be testing for
>> compiler features directly, not keep a list of what compilers are
>> supported in the code...
>
> Yes, I can revert this if you insist. And don't mind that all those
> horribly broken ebuilds checking gcc versions will suddenly fail with
> clang.

So fix them properly, by detecting compiler features, not compiler name ;)

>> The point of eclasses is to share code and make ebuild maintenance
>> easier. I don't see how allowing version checks for GCC only, when clang
>> is supported by a lot of ebuilds, makes that easier. Again, if you're so
>> opposed to compiler specific checks, then please remove them from
>> ebuilds using them and from toolchains-funcs.eclass (or at least mark
>> them as deprecated).
>
> How does ebuild maintenance become easier when you have to test a dozen
> of versions of different compilers to figure out which one is
> supported?

My goal is clang support parity with gcc. If you are opposed to these
sort of checks, then why don't we deprecate and remove those functions?
I want to know why gcc deserves special treatment, either all compilers
should have easy way to check major/minor/full versions, or none should.
Obviously I'm not saying gcc should be removed now, but it could
certainly be marked deprecated so the usage doesn't spread (hopefully)
further.

-- 
-Austin
GPG: 00B3 2957 B94B F3E1