[csw-maintainers] Reasons for gcc to have a separate prefix
Maciej Bliziński
maciej at opencsw.org
Sat Aug 27 13:27:49 CEST 2011
Hi Peter,
Thanks a lot for the write-up. You're helping us avoid the old mistakes.
2011/8/26 Peter FELECAN <pfelecan at opencsw.org>:
> * History:
> - gcc2:
> - until the end of 2004 it was maintained by Phil Brown and Markus Gyger
> - I took it up and provided the packages
> - at that time, some projects' preferred compiler set was that
> branch, e.g., MPlayer
That would be the biggest problem with deprecating old compilers. I
think it might occur again when gcc does a major update in the future,
so we need to have a plan.
> - gcc3
> - same story as for gcc2
> - the last supported version for this branch, 3.4.6, is available
> - gcc4
> - I maintained this branch since March 2005, the last version that I
> delivered was 4.0.2
> - after 2006, Mike Waters was the maintainer for this branch
> * Prefix:
> the separate prefix was the rule from the beginning and it was
> enforced by the previous release manager; I proposed at the time an
> alternatives system but to no avail, BTW, this is why I implemented a
> specific alternative system for Emacs.
> * Proposition for the future:
> Support only one branch, 4, but use alternatives for supporting
> different releases and make provision for a 5th branch; I think that
> I can release a branch 3 package using alternatives after it's
> implemented in the 4th.
The gcc build system supports adding a binary prefix, so we could set
it to something like "gcc4" and have gcc4gcc, gcc4g++, etc. That would
also start matching the package names.
However, alternatives are not a viable solution for the buildfarm. We
all work on the same hosts and we need to make it possible to build
with gccN and gcc(N+1) at the same time. You can't have buildfarm
admins flip symlink every time a maintainer wants to switch between
e.g. gcc-3 and gcc-4.
How about this plan:
- we support one current/blessed version of gcc, which lives in /opt/csw
- when there's a need to have an old version of gcc available, we
recompile the old version into a separate prefix, as a legacy mode
The algorithm goes like this:
T = 1
gccN: prefix=/opt/csw
T = 2
gccN: prefix=/opt/csw/gccN (recompile)
gcc(N+1): prefix=/opt/csw
T = 3
gccN: prefix=/opt/csw/gccN
gcc(N+1): prefix=/opt/csw/gcc(N+1)
gcc(N+2): prefix=/opt/csw
etc.
The annoying part of this plan is that you have to recompile the old
version of gcc to make it available, you can't just let the packages
be. When you replace gccN with gcc(N+1), you have to make the extra
effort of moving gccN into own prefix. I consider it a reasonable
trade off.
Maciej
More information about the maintainers
mailing list