Re: GCC multi-version development layout

Sent with Proton Mail secure email.

On Monday, April 20th, 2026 at 12:34 AM, Jonathan Wakely <[email protected]> wrote:

> 
> 
> On Sun, 19 Apr 2026, 23:30 Heime, <[email protected]> wrote:
> 
> > On Sunday, April 19th, 2026 at 7:50 PM, Jonathan Wakely via Gcc-help <[email protected]> wrote:
> > 
> > > On Sun, 19 Apr 2026, 17:57 Xi Ruoyao via Gcc-help, <[email protected]>
> > > wrote:
> > >
> > > > On Sun, 2026-04-19 at 16:33 +0000, Heime via Gcc-help wrote:
> > > > > ----------------------------------------------------------------
> > > > >
> > > > > When building GCC from a cloned Git source tree using separate
> > > > > directories (as recommended), the directory structure follows
> > > > > a clean separation of source, build artifacts, and final
> > > > > installation.
> > > > >
> > > > > With different version of gcc, how would be the typical layout
> > > > > for specific branches to make patch changes to different gcc
> > > > > versions with multiple builds and install?
> > > >
> > >
> > > The layout doesn't matter at all. Anything will work.
> > >
> > > I have a directory ~/src/gcc/gcc for the git repo, where I work on trunk
> > > and then directories ~/src/gcc/gcc-15 and ~/src/gcc/gcc-14 etc for each
> > > release branch, using git worktree.
> > >
> > > I install each version to ~/gcc/X where X is 16, 15, 14 etc.
> > >
> > > But it really doesn't matter, anything works.
> > >
> > >
> > > > See https://git-scm.com/docs/git-worktree.
> > > >
> > >
> > > This is definitely the best way to manage the repo, so that every release
> > > branch is just a worktree using the same repository metadata and config
> > > settings.
> > 
> > Have been scrutinising the development timeline page
> > 
> > https://gcc.gnu.org/develop.html#timeline
> > 
> > The new GCC versioning scheme announced for GCC 5.1 is
> > not reliably described. For instance, a major version
> > number increases GCC X to GCC X+1 (no more GCC X.Y to
> > GCC X.Y+1).
> > 
> > The stage number does not seem to be added as a version
> > (there is no GCC X.0.1 (for stage 1), GCC X.0.3 (for stage 3)),
> > and so on.
> 
> 
> That's correct.
> 
> 
> > 
> > 
> > It would help if the page got updated with improved descriptions.
> 
> 
> 
> I don't see a problem with it, what improvement are you suggesting?

I read "Version Numbering Scheme for GCC 5 and Up"

Starting example table shows 

5.0.0	(experimental) 	during active development of GCC 5 (stage 1 to 3)
5.0.1	(experimental) 	during the stabilization period of GCC 5 (stage 4)
5.0.1	(prerelease)

So stage changes and pre-releases do not show obvious numeric changes
to GCC-N-Y-Z.  A more thorough description the current Version Numbering 
Scheme would help make things understandable, or instill some more obvious
Version Numbering Scheme that reflects what one sees in GCC-N-Y-Z.  Major
version now consists of incrementing X, not incrementing Y (as with GCC 4.9
and previous).

With "Rationale" followed by "Release Timeline".

"Rationale" is too succinct, stating only that 

This change allows to more easily identify GCC versions by giving 
each of the development phases distinctive versions.

"Release Timeline" shows only that they are releases but not
much about their meaning.