Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 May 2016 14:41:07 -0700
From:      Mark Millard <markmi@dsl-only.net>
To:        FreeBSD Current <freebsd-current@freebsd.org>, Bryan Drewery <bdrewery@FreeBSD.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>
Subject:   Re: WITH_SYSTEM_COMPILER: Skip Clang/GCC bootstrap [Critical note for Toolchain changes]
Message-ID:  <986EF3DE-84DA-4867-AD94-384EA3733144@dsl-only.net>

next in thread | raw e-mail | index | archive | help
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:
>=20
> 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?

=3D=3D=3D
Mark Millard
markmi@dsl-only.net




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?986EF3DE-84DA-4867-AD94-384EA3733144>