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?
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...
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).
--
-Austin
GPG: 00B3 2957 B94B F3E1
signature.asc
Description: OpenPGP digital signature
