Date: Tue, 13 Aug 2019 10:00:30 -0600 From: Warner Losh <imp@bsdimp.com> To: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline Message-ID: <CANCZdfrZ-C37c7Eso7NrtMG5_kv3T9qO3c3k8xcgEeTCrY3nQg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Greetings, As promised for almost the past decade or so, gcc 4.2.1 will be removed from the tree before FreeBSD 13 is branched. I propose the following timeline for its removal: 2019-08-31: disconnect gcc 4.2.1 from CI build Turn off -Werror on gcc 4.2.1 platforms Turn off all gcc 4.2.1 from universe by default (can be turned on) 2019-12-31: Turn off gcc 4.2.1 build by default (can be turned on) 2020-03-31: svn rm gcc 4.2.1 and friends 2020-05-31: svn rm all non-clang platforms not supported by in-tree LLVM or converted to ext toolchain. 2020-07-31: svn rm all ext toolchain platforms not supported by re@ release scripts The basic notion is that it=E2=80=99s long past time to have a firm plan fo= r EOL gcc 4.2.1 in the tree. There is ample external toolchain support today for platforms that need it to build images, though that integration with buildworld could use some more polish. It=E2=80=99s now completely sufficie= nt to move to the next phase of removing gcc 4.2.1 from the tree. We already have gcc 6.4 as an xtoolchain on amd64 in CI. This should somewhat mitigate the risk for cross-compiler portability. This is a long-established part of our CI. We want to retain gcc support for modern versions of gcc since its debuggability is higher. Notifications for this are currently turned off, but will be enabled soon. It=E2=80=99s expected t= hat this always will be working later in the year. We=E2=80=99ll work to update the committers guide to reflect this, as well as give a recipe for testing. The first phase will be at the end of the month. We=E2=80=99ll turn off -We= rror on gcc 4.2.1 (and MFC it to stable/11 and stable/12). We=E2=80=99ll then stop = building all platforms that require it as part of CI. New warnings will come up, but will no longer waste developer time in trying to fix. Gcc 4.2.1 platforms will no longer be built as part of universe, unless you add -DMAKE_OBSOLETE_GCC is added to the command line. We plan on implementing this by 2019-08-31. An experimental branch will be created that will remove gcc related bits to expose gaps in planning and to come up with a list of action items needed to ensure Tier 1 platforms are unaffected by the gcc removal. The timeline for this is by the end of September. Next, we=E2=80=99ll turn off building gcc by default. This will effectively= break all gcc platforms with in-tree compilers. The external toolchain support we have will suffice here, and patches will be accepted for whatever integration are needed for these platforms with our current ports / packages. The onus for these changes will be squarely on people that want the platforms to continue. However, as a stop-gap gcc building can be turned on for those people transitioning gcc-only platforms until gcc 4.2.1 is removed. This will happen on or about 2019-12-31. After a 3 month transition period, gcc 4.2.1 will be removed from the tree. This will be done on or about 2020-03-31. After an additional 2 month transition period, all those platforms that have not integrated with the FreeBSD CI system, work in a make universe with the proper packages installed, and are shown to boot on real hardware will be removed from the tree. This will happen on or about 2020-05-31. After an additional 2 month grace period, those platforms that require external toolchain integration that aren=E2=80=99t supported by the release engineer=E2=80=99s release scripts will be removed. This will happen on or= about 2020-07-31. The timeline gives powerpc, mips, mips64, and sparc64 9 months to integrate either into an in-tree compiler, or to have a proven external toolchain solution. This is on top of the many-years-long warnings about this being the end game of the clang integration. This is the proposed timeline, but should there be a significant issue that=E2=80=99s discovered, the timeline can be amended. Also note: the all toolchains in tree discussions are specifically out of bounds here. Let=E2=80=99s remove one compiler and get the infrastructure n= eeded to make external toolchains robust before embarking on that discussion. Comments? Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrZ-C37c7Eso7NrtMG5_kv3T9qO3c3k8xcgEeTCrY3nQg>