On 2016-May-23, at 2:50 PM, Bryan Drewery <bdrewery at FreeBSD.org> wrote: > On 5/23/16 2:41 PM, Mark Millard wrote: >> Relative to (Bryan Drewery Mon May 23 16:40:23 UTC 2016): >> >>> A critical note to toolchain developers, or anyone who touches the Clang >>> or GCC source files. If you modify these files or add a new target >>> architecture into Clang, please bump the revision in the appropriate file: >>> >>> Clang: lib/clang/include/clang/Basic/Version.inc FREEBSD_CC_VERSION >>> GCC: gnu/usr.bin/cc/cc_tools/freebsd-native.h FBSD_CC_VER >> >> quoting from https://svnweb.freebsd.org/changeset/base/300354 : >> >>> This relies on the macros being incremented whenever any change occurs >>> to these compilers that warrant rebuilding files. It also should never >>> repeat earlier values. >> >> It appears that someone that tries to make or test clang patches without using a committer bit to be the one updating the official source will have trouble meeting this criteria. I've been in that situation in the past. Reverting back to, say, CURRENT after a patch is adopted is another example of version number progression problems. >> > > If you are testing a local patch you can modify the files yourself as > well. Or just set WITHOUT_SYSTEM_COMPILER. But what temporary private value assignment will only "increment" and yet "never repeat repeat earlier values" once the temporary period is over and official numbering again is in use? Looks to me like WITHOUT_SYSTEM_COMPILER is required for such contexts. >> It may be that official value updates to FREEBSD_CC_VERSION should be spaced apart leaving versions available between official version numbers for such local activities without version identification conflicts. >> >> There are also projects such as the /project/clang*-import ones that might have version number transition issues between it and CURRENT at various stages for those working on the project and anyone that is just following the project while it is active. I followed clang380-import and reported on some powerpc64/powerpc/armv6 issues during the project so I've been in this situation in the past. >> > > For project branches they could just use some unique number or disable > the option. So in some contexts the "increment" and/or "never repeat repeat earlier values" do not apply (including when a temporary local assignment goes to no longer being in use)? It still looks to me like WITHOUT_SYSTEM_COMPILER is required for such contexts. >> It is not clear to me what the right things would have been to do and when to do it if this FREEBSD_CC_VERSION criteria had been in place at the time. >> >> Similar comments probably apply to FBSD_CC_VER and gcc/g++. >> >> Is it as simple as "never use WITH_SYSTEM_COMPILER" for patch/update explorations that are not yet official commits on CURRENT or STABLE? Does the version number involved then matter? >> >> === >> Mark Millard >> markmi at dsl-only.net <mailto:markmi_at_dsl-only.net> >> > > > -- > Regards, > Bryan Drewery === Mark Millard markmi at dsl-only.netReceived on Mon May 23 2016 - 21:46:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:05 UTC