On 07/05/2016 12:00 AM, Michał Górny wrote: > On Mon, 4 Jul 2016 19:16:55 -0500 > Austin English <[email protected]> wrote: > >> On 07/01/2016 03:02 PM, Michał Górny wrote: >>> On Mon, 27 Jun 2016 17:04:41 -0500 >>> Austin English <[email protected]> wrote: >>> >>>> From ec0be3d1a808ea0c5bdd081a4bb935f86bf78d44 Mon Sep 17 00:00:00 2001 >>>> From: Austin English <[email protected]> >>>> 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
signature.asc
Description: OpenPGP digital signature
