* [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions @ 2016-06-27 22:04 Austin English 2016-07-01 20:02 ` Michał Górny 0 siblings, 1 reply; 6+ messages in thread From: Austin English @ 2016-06-27 22:04 UTC (permalink / raw To: toolchain; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1804 bytes --] From ec0be3d1a808ea0c5bdd081a4bb935f86bf78d44 Mon Sep 17 00:00:00 2001 From: Austin English <wizardedit@gentoo.org> Date: Mon, 27 Jun 2016 16:58:07 -0500 Subject: [PATCH 2/2] eclass/toolchain-funcs: add clang version functions Signed-off-by: Austin English <wizardedit@gentoo.org> --- eclass/toolchain-funcs.eclass | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass index fb8b2f9..9bb5232 100644 --- a/eclass/toolchain-funcs.eclass +++ b/eclass/toolchain-funcs.eclass @@ -642,6 +642,39 @@ gcc-micro-version() { _gcc_fullversion '$3' "$@" } +# Internal func. Based on _gcc_fullversion() above. +_clang_fullversion() { + local ver="$1"; shift + set -- $($(tc-getCPP "$@") -E -P - <<<"__clang_major__ __clang_minor__ __clang_patchlevel__") + eval echo "$ver" +} + +# @FUNCTION: clang-fullversion +# @RETURN: compiler version (major.minor.micro: [3.4.6]) +clang-fullversion() { + _clang_fullversion '$1.$2.$3' "$@" +} +# @FUNCTION: clang-version +# @RETURN: compiler version (major.minor: [3.4].6) +clang-version() { + _clang_fullversion '$1.$2' "$@" +} +# @FUNCTION: clang-major-version +# @RETURN: major compiler version (major: [3].4.6) +clang-major-version() { + _clang_fullversion '$1' "$@" +} +# @FUNCTION: clang-minor-version +# @RETURN: minor compiler version (minor: 3.[4].6) +clang-minor-version() { + _clang_fullversion '$2' "$@" +} +# @FUNCTION: clang-micro-version +# @RETURN: micro compiler version (micro: 3.4.[6]) +clang-micro-version() { + _clang_fullversion '$3' "$@" +} + # Returns the installation directory - internal toolchain # function for use by _gcc-specs-exists (for flag-o-matic). _gcc-install-dir() { -- 2.7.3 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions 2016-06-27 22:04 [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions Austin English @ 2016-07-01 20:02 ` Michał Górny 2016-07-05 0:16 ` Austin English 0 siblings, 1 reply; 6+ messages in thread From: Michał Górny @ 2016-07-01 20:02 UTC (permalink / raw To: Austin English; +Cc: toolchain, gentoo-dev [-- Attachment #1: Type: text/plain, Size: 819 bytes --] On Mon, 27 Jun 2016 17:04:41 -0500 Austin English <wizardedit@gentoo.org> wrote: > From ec0be3d1a808ea0c5bdd081a4bb935f86bf78d44 Mon Sep 17 00:00:00 2001 > From: Austin English <wizardedit@gentoo.org> > 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? 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. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 949 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions 2016-07-01 20:02 ` Michał Górny @ 2016-07-05 0:16 ` Austin English 2016-07-05 5:00 ` Michał Górny 0 siblings, 1 reply; 6+ messages in thread From: Austin English @ 2016-07-05 0:16 UTC (permalink / raw To: gentoo-dev; +Cc: toolchain [-- Attachment #1.1: Type: text/plain, Size: 1836 bytes --] On 07/01/2016 03:02 PM, Michał Górny wrote: > On Mon, 27 Jun 2016 17:04:41 -0500 > Austin English <wizardedit@gentoo.org> wrote: > >> From ec0be3d1a808ea0c5bdd081a4bb935f86bf78d44 Mon Sep 17 00:00:00 2001 >> From: Austin English <wizardedit@gentoo.org> >> 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions 2016-07-05 0:16 ` Austin English @ 2016-07-05 5:00 ` Michał Górny 2016-07-05 6:08 ` Austin English 0 siblings, 1 reply; 6+ messages in thread From: Michał Górny @ 2016-07-05 5:00 UTC (permalink / raw To: Austin English; +Cc: gentoo-dev, toolchain [-- Attachment #1: Type: text/plain, Size: 2911 bytes --] On Mon, 4 Jul 2016 19:16:55 -0500 Austin English <wizardedit@gentoo.org> wrote: > On 07/01/2016 03:02 PM, Michał Górny wrote: > > On Mon, 27 Jun 2016 17:04:41 -0500 > > Austin English <wizardedit@gentoo.org> wrote: > > > >> From ec0be3d1a808ea0c5bdd081a4bb935f86bf78d44 Mon Sep 17 00:00:00 2001 > >> From: Austin English <wizardedit@gentoo.org> > >> 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. 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. > 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? -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 949 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions 2016-07-05 5:00 ` Michał Górny @ 2016-07-05 6:08 ` Austin English 2016-07-05 17:47 ` waltdnes 0 siblings, 1 reply; 6+ messages in thread From: Austin English @ 2016-07-05 6:08 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 3519 bytes --] On 07/05/2016 12:00 AM, Michał Górny wrote: > On Mon, 4 Jul 2016 19:16:55 -0500 > Austin English <wizardedit@gentoo.org> wrote: > >> On 07/01/2016 03:02 PM, Michał Górny wrote: >>> On Mon, 27 Jun 2016 17:04:41 -0500 >>> Austin English <wizardedit@gentoo.org> wrote: >>> >>>> From ec0be3d1a808ea0c5bdd081a4bb935f86bf78d44 Mon Sep 17 00:00:00 2001 >>>> From: Austin English <wizardedit@gentoo.org> >>>> 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions 2016-07-05 6:08 ` Austin English @ 2016-07-05 17:47 ` waltdnes 0 siblings, 0 replies; 6+ messages in thread From: waltdnes @ 2016-07-05 17:47 UTC (permalink / raw To: gentoo-dev On Tue, Jul 05, 2016 at 01:08:13AM -0500, Austin English wrote > > 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. This is reminiscent of the web-browser situation. I use Pale Moon. It's feature-compatible with Firefox, but has not gone berserk with the version numbering. The current Firefox is 49-point-something. Stupid webpages see Pale Moon 26.3.3 and whine about "out-of-date-web-browser" and kick the user out. But if the user sets the user agent (i.e. lies to the webpage) that he's using Firefox 49.1, it works just fine. It's not unique to the current FOS world, either. Some old MS-DOS applications would only run when the OS reported a certain narrow range of versions. When you updated MS-DOS, some older applications would refuse to run, even though the newer MS-DOS was perfectly capable of running it. Things got so bad that Microsoft introduced the SETVER command https://support.microsoft.com/en-us/kb/96767 to deliberately lie about the MS-DOS version number, when queried by specific applications. How is the version checking done? Does the check parse the file name of the compiler? Can we get the GCC and CLANG people to agree to a common command/parameter that returns a compatibility level for "version-checking"? -- Walter Dnes <waltdnes@waltdnes.org> I don't run "desktop environments"; I run useful applications ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-07-05 17:47 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-06-27 22:04 [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions Austin English 2016-07-01 20:02 ` Michał Górny 2016-07-05 0:16 ` Austin English 2016-07-05 5:00 ` Michał Górny 2016-07-05 6:08 ` Austin English 2016-07-05 17:47 ` waltdnes
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox