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. -- Will Newton Toolchain Working Group, Linaro _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
