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. 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. 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.netReceived on Mon May 23 2016 - 20:41:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:05 UTC