1 |
On 07/01/2016 03:02 PM, Michał Górny wrote: |
2 |
> On Mon, 27 Jun 2016 17:04:41 -0500 |
3 |
> Austin English <wizardedit@g.o> wrote: |
4 |
> |
5 |
>> From ec0be3d1a808ea0c5bdd081a4bb935f86bf78d44 Mon Sep 17 00:00:00 2001 |
6 |
>> From: Austin English <wizardedit@g.o> |
7 |
>> Date: Mon, 27 Jun 2016 16:58:07 -0500 |
8 |
>> Subject: [PATCH 2/2] eclass/toolchain-funcs: add clang version functions |
9 |
> |
10 |
> Why do you even ask for review if you can't wait till the weekend |
11 |
> before committing? |
12 |
|
13 |
There's no set time limit that I could find anywhere. I checked with my |
14 |
mentor first, who said a few days was enough (as there were no comments |
15 |
by anyone). |
16 |
|
17 |
> I've already told you twice that I'm opposed to adding version querying |
18 |
> functions for clang, especially for the use case you proposed. You |
19 |
> should check for features, and not keep a huge list of supported gcc, |
20 |
> clang, pathcc, icc... versions. With every random compiler pretending |
21 |
> to be a random version of every other compiler. |
22 |
|
23 |
I did not use in the original intended case, however I think that these |
24 |
helpers are still useful. Why do we allow gcc version checks then? |
25 |
There's no deprecated comment for these functions. By that logic, you |
26 |
should not have added tc-is-{gcc,clang}, 2 weeks ago in |
27 |
6984a5b149a215dd96a9759d3d1f251354faf38f. You should be testing for |
28 |
compiler features directly, not keep a list of what compilers are |
29 |
supported in the code... |
30 |
|
31 |
The point of eclasses is to share code and make ebuild maintenance |
32 |
easier. I don't see how allowing version checks for GCC only, when clang |
33 |
is supported by a lot of ebuilds, makes that easier. Again, if you're so |
34 |
opposed to compiler specific checks, then please remove them from |
35 |
ebuilds using them and from toolchains-funcs.eclass (or at least mark |
36 |
them as deprecated). |
37 |
|
38 |
-- |
39 |
-Austin |
40 |
GPG: 00B3 2957 B94B F3E1 |