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 <c...@codeaurora.org> wrote: > On 10/24/2014 10:20 AM, Christophe Lyon wrote: >> On 23 October 2014 12:00, Will Newton <will.new...@linaro.org> wrote: >>> On 23 October 2014 10:44, Yvan Roux <yvan.r...@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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
