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. :-/ > > 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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
