On Oct 23, 2014, at 10:44 PM, 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: > > ... > 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 mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
