Hi,
after the recent lkml thread on blacklisting some GCC versions (see below) and the issue in identifying accurately our releases, I propose to add some Linaro specific macros in our branches (i.e this patch will not go upstream) to be able to check the Linaro version at preprocessor time. It will not solve the kernel issue with 4.8.N but hopefully help if such issues happen again the the futur.
http://thread.gmane.org/gmane.linux.ports.arm.omap/119412
What GCC has for the moment is 3 macros __GNUC__, __GNUC_MINOR__ and __GNUC_PATCHLEVEL__ that are filled by parsing version number contained in BASE-VER file, for instance on our 4.9 branch:
__GNUC__ = 4 __GNUC_MINOR__ = 9 __GNUC_PATCHLEVEL__ = 2
In our branches, the Linaro version number is in the LINARO-VERSION file and has this format:
At release point : 4.9-2014.10 Head of our branch: 4.9-2014.10-1~dev
I want your (the team and users) point of view on the macros we need to create from it. Here is the options I see:
A - Be fully Linaro consistent:
__LINARO_MAJOR__ = 4 __LINARO_MINOR__ = 9 __LINARO_YEAR__ = 2014 __LINARO_MONTH__ = 10 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
B - Only give information that are not in the __GNUC* macros:
__LINARO_YEAR__ = 2014 __LINARO_MONTH__ = 10 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
C - Be more concise:
__LINARO_VERSION__ = 201410 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
D - Even more:
__LINARO_VERSION__ = 201410N (with N the spin number) __LINARO_STATE = 0 for release or 1 for dev
E - Hardcore conciseness:
__LINARO__ = 201410NM (N = SPIN M = state)
F - One of the previous ones without STATE information.
G - One of the previous ones without SPIN information.
Do you think it is something we need ?
Do we already have that kind of macros in some products (binutils, gdb, glibc, ...) ?
What option do you prefer ?
My own feeling is that C+F is sufficient as STATE information is useless for releases and I don't think dev builds checking have to be used in another project. But SPIN information can be useful has we're doing respin because an outstanding issue/improvement has to be fixed/added to the current release, thus it is the kind of thing you want to check if the version of the compiler you are using contains.
Thanks, Yvan
On 23 October 2014 10:44, Yvan Roux yvan.roux@linaro.org wrote:
Hi,
after the recent lkml thread on blacklisting some GCC versions (see below) and the issue in identifying accurately our releases, I propose to add some Linaro specific macros in our branches (i.e this patch will not go upstream) to be able to check the Linaro version at preprocessor time. It will not solve the kernel issue with 4.8.N but hopefully help if such issues happen again the the futur.
http://thread.gmane.org/gmane.linux.ports.arm.omap/119412
What GCC has for the moment is 3 macros __GNUC__, __GNUC_MINOR__ and __GNUC_PATCHLEVEL__ that are filled by parsing version number contained in BASE-VER file, for instance on our 4.9 branch:
__GNUC__ = 4 __GNUC_MINOR__ = 9 __GNUC_PATCHLEVEL__ = 2
In our branches, the Linaro version number is in the LINARO-VERSION file and has this format:
At release point : 4.9-2014.10 Head of our branch: 4.9-2014.10-1~dev
I want your (the team and users) point of view on the macros we need to create from it. Here is the options I see:
A - Be fully Linaro consistent:
__LINARO_MAJOR__ = 4 __LINARO_MINOR__ = 9 __LINARO_YEAR__ = 2014 __LINARO_MONTH__ = 10 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
B - Only give information that are not in the __GNUC* macros:
__LINARO_YEAR__ = 2014 __LINARO_MONTH__ = 10 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
C - Be more concise:
__LINARO_VERSION__ = 201410 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
D - Even more:
__LINARO_VERSION__ = 201410N (with N the spin number) __LINARO_STATE = 0 for release or 1 for dev
E - Hardcore conciseness:
__LINARO__ = 201410NM (N = SPIN M = state)
F - One of the previous ones without STATE information.
G - One of the previous ones without SPIN information.
Do you think it is something we need ?
Do we already have that kind of macros in some products (binutils, gdb, glibc, ...) ?
What option do you prefer ?
My own feeling is that C+F is sufficient as STATE information is useless for releases and I don't think dev builds checking have to be used in another project. But SPIN information can be useful has we're doing respin because an outstanding issue/improvement has to be fixed/added to the current release, thus it is the kind of thing you want to check if the version of the compiler you are using contains.
Personally I think I would go D+F, but with two digits for the spin:
__LINARO_VERSION__ = 201410NN (with NN the spin number)
I guess that could be misread as a date though. :-/
So maybe C+F is better. I agree that the dev/release state should not matter as dev versions do not really exist outside of our own machines.
On 23 October 2014 12:00, Will Newton will.newton@linaro.org wrote:
On 23 October 2014 10:44, Yvan Roux yvan.roux@linaro.org wrote:
Hi,
after the recent lkml thread on blacklisting some GCC versions (see below) and the issue in identifying accurately our releases, I propose to add some Linaro specific macros in our branches (i.e this patch will not go upstream) to be able to check the Linaro version at preprocessor time. It will not solve the kernel issue with 4.8.N but hopefully help if such issues happen again the the futur.
http://thread.gmane.org/gmane.linux.ports.arm.omap/119412
What GCC has for the moment is 3 macros __GNUC__, __GNUC_MINOR__ and __GNUC_PATCHLEVEL__ that are filled by parsing version number contained in BASE-VER file, for instance on our 4.9 branch:
__GNUC__ = 4 __GNUC_MINOR__ = 9 __GNUC_PATCHLEVEL__ = 2
In our branches, the Linaro version number is in the LINARO-VERSION file and has this format:
At release point : 4.9-2014.10 Head of our branch: 4.9-2014.10-1~dev
I want your (the team and users) point of view on the macros we need to create from it. Here is the options I see:
A - Be fully Linaro consistent:
__LINARO_MAJOR__ = 4 __LINARO_MINOR__ = 9 __LINARO_YEAR__ = 2014 __LINARO_MONTH__ = 10 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
B - Only give information that are not in the __GNUC* macros:
__LINARO_YEAR__ = 2014 __LINARO_MONTH__ = 10 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
C - Be more concise:
__LINARO_VERSION__ = 201410 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
D - Even more:
__LINARO_VERSION__ = 201410N (with N the spin number) __LINARO_STATE = 0 for release or 1 for dev
E - Hardcore conciseness:
__LINARO__ = 201410NM (N = SPIN M = state)
F - One of the previous ones without STATE information.
G - One of the previous ones without SPIN information.
Do you think it is something we need ?
Do we already have that kind of macros in some products (binutils, gdb, glibc, ...) ?
What option do you prefer ?
My own feeling is that C+F is sufficient as STATE information is useless for releases and I don't think dev builds checking have to be used in another project. But SPIN information can be useful has we're doing respin because an outstanding issue/improvement has to be fixed/added to the current release, thus it is the kind of thing you want to check if the version of the compiler you are using contains.
Personally I think I would go D+F, but with two digits for the spin:
__LINARO_VERSION__ = 201410NN (with NN the spin number)
I guess that could be misread as a date though. :-/
So maybe C+F is better. I agree that the dev/release state should not matter as dev versions do not really exist outside of our own machines.
I agree with Will.
Christophe.
-- Will Newton Toolchain Working Group, Linaro
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On 10/24/2014 10:20 AM, Christophe Lyon wrote:
On 23 October 2014 12:00, Will Newton will.newton@linaro.org wrote:
On 23 October 2014 10:44, Yvan Roux yvan.roux@linaro.org wrote:
Hi,
after the recent lkml thread on blacklisting some GCC versions (see below) and the issue in identifying accurately our releases, I propose to add some Linaro specific macros in our branches (i.e this patch will not go upstream) to be able to check the Linaro version at preprocessor time. It will not solve the kernel issue with 4.8.N but hopefully help if such issues happen again the the futur.
http://thread.gmane.org/gmane.linux.ports.arm.omap/119412
What GCC has for the moment is 3 macros __GNUC__, __GNUC_MINOR__ and __GNUC_PATCHLEVEL__ that are filled by parsing version number contained in BASE-VER file, for instance on our 4.9 branch:
__GNUC__ = 4 __GNUC_MINOR__ = 9 __GNUC_PATCHLEVEL__ = 2
In our branches, the Linaro version number is in the LINARO-VERSION file and has this format:
At release point : 4.9-2014.10 Head of our branch: 4.9-2014.10-1~dev
I want your (the team and users) point of view on the macros we need to create from it. Here is the options I see:
A - Be fully Linaro consistent:
__LINARO_MAJOR__ = 4 __LINARO_MINOR__ = 9 __LINARO_YEAR__ = 2014 __LINARO_MONTH__ = 10 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
B - Only give information that are not in the __GNUC* macros:
__LINARO_YEAR__ = 2014 __LINARO_MONTH__ = 10 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
C - Be more concise:
__LINARO_VERSION__ = 201410 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
D - Even more:
__LINARO_VERSION__ = 201410N (with N the spin number) __LINARO_STATE = 0 for release or 1 for dev
E - Hardcore conciseness:
__LINARO__ = 201410NM (N = SPIN M = state)
F - One of the previous ones without STATE information.
G - One of the previous ones without SPIN information.
Do you think it is something we need ?
Do we already have that kind of macros in some products (binutils, gdb, glibc, ...) ?
What option do you prefer ?
My own feeling is that C+F is sufficient as STATE information is useless for releases and I don't think dev builds checking have to be used in another project. But SPIN information can be useful has we're doing respin because an outstanding issue/improvement has to be fixed/added to the current release, thus it is the kind of thing you want to check if the version of the compiler you are using contains.
Personally I think I would go D+F, but with two digits for the spin:
__LINARO_VERSION__ = 201410NN (with NN the spin number)
I guess that could be misread as a date though. :-/
Do you expect to make more than one spin in a day? Do you expect to make a lower-numbered spin at a later date? If the answers are no, then why not simply use YYYYMMDD? Just in case you could document that under unusual circumstances, such as the above, the day may be slightly off, but that arithmetic comparison operators will work as expected.
Chris
Hi,
Thanks for the feedback, in theory it is possible to have more than one spin in day but in practice I really think/hope it will never happen, and yes spin numbers are a strictly monotonically increasing sequence. The date format is an option but I think that having a mismatch between these macros and the tarballs names and release notes which includes the spin number makes it less usable.
I'm up for the __LINARO_RELEASE__ macro of format YYYYMM but I'd keep the __LINARO_SPIN__ macro, last month release had to be respinned because of a merge issue and with __LINARO_RELEASE__ alone we're not able to distinguish the 2 releases.
I've a patch that implements this option, but I'm still ready to change it if most of you prefer the YYYYMM or YYYYMMSS format.
Yvan
On 24 October 2014 16:48, Christopher Covington cov@codeaurora.org wrote:
On 10/24/2014 10:20 AM, Christophe Lyon wrote:
On 23 October 2014 12:00, Will Newton will.newton@linaro.org wrote:
On 23 October 2014 10:44, Yvan Roux yvan.roux@linaro.org wrote:
Hi,
after the recent lkml thread on blacklisting some GCC versions (see below) and the issue in identifying accurately our releases, I propose to add some Linaro specific macros in our branches (i.e this patch will not go upstream) to be able to check the Linaro version at preprocessor time. It will not solve the kernel issue with 4.8.N but hopefully help if such issues happen again the the futur.
http://thread.gmane.org/gmane.linux.ports.arm.omap/119412
What GCC has for the moment is 3 macros __GNUC__, __GNUC_MINOR__ and __GNUC_PATCHLEVEL__ that are filled by parsing version number contained in BASE-VER file, for instance on our 4.9 branch:
__GNUC__ = 4 __GNUC_MINOR__ = 9 __GNUC_PATCHLEVEL__ = 2
In our branches, the Linaro version number is in the LINARO-VERSION file and has this format:
At release point : 4.9-2014.10 Head of our branch: 4.9-2014.10-1~dev
I want your (the team and users) point of view on the macros we need to create from it. Here is the options I see:
A - Be fully Linaro consistent:
__LINARO_MAJOR__ = 4 __LINARO_MINOR__ = 9 __LINARO_YEAR__ = 2014 __LINARO_MONTH__ = 10 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
B - Only give information that are not in the __GNUC* macros:
__LINARO_YEAR__ = 2014 __LINARO_MONTH__ = 10 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
C - Be more concise:
__LINARO_VERSION__ = 201410 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
D - Even more:
__LINARO_VERSION__ = 201410N (with N the spin number) __LINARO_STATE = 0 for release or 1 for dev
E - Hardcore conciseness:
__LINARO__ = 201410NM (N = SPIN M = state)
F - One of the previous ones without STATE information.
G - One of the previous ones without SPIN information.
Do you think it is something we need ?
Do we already have that kind of macros in some products (binutils, gdb, glibc, ...) ?
What option do you prefer ?
My own feeling is that C+F is sufficient as STATE information is useless for releases and I don't think dev builds checking have to be used in another project. But SPIN information can be useful has we're doing respin because an outstanding issue/improvement has to be fixed/added to the current release, thus it is the kind of thing you want to check if the version of the compiler you are using contains.
Personally I think I would go D+F, but with two digits for the spin:
__LINARO_VERSION__ = 201410NN (with NN the spin number)
I guess that could be misread as a date though. :-/
Do you expect to make more than one spin in a day? Do you expect to make a lower-numbered spin at a later date? If the answers are no, then why not simply use YYYYMMDD? Just in case you could document that under unusual circumstances, such as the above, the day may be slightly off, but that arithmetic comparison operators will work as expected.
Chris
-- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
On Oct 23, 2014, at 10:44 PM, Yvan Roux yvan.roux@linaro.org wrote:
Hi,
after the recent lkml thread on blacklisting some GCC versions (see below) and the issue in identifying accurately our releases, I propose to add some Linaro specific macros in our branches (i.e this patch will not go upstream) to be able to check the Linaro version at preprocessor time. It will not solve the kernel issue with 4.8.N but hopefully help if such issues happen again the the futur.
http://thread.gmane.org/gmane.linux.ports.arm.omap/119412
What GCC has for the moment is 3 macros __GNUC__, __GNUC_MINOR__ and __GNUC_PATCHLEVEL__ that are filled by parsing version number contained in BASE-VER file, for instance on our 4.9 branch:
...
C - Be more concise:
__LINARO_VERSION__ = 201410 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev
I'm for __LINARO_RELEASE__ macro of format YYYYMM. I would not define the state macro as only release-class toolchains should be used by the public; people always use dev-class toolchains at their own risk. I would not define the spin macro either, at least until we get ourselves in a case that can't be resolved by __LINARO_RELEASE__ alone.
Thank you,
-- Maxim Kuvyrkov www.linaro.org
linaro-toolchain@lists.linaro.org
-
Christophe Lyon -
Christopher Covington -
Maxim Kuvyrkov -
Will Newton -
Yvan Roux