* Re: "Split GNAT compilers" in Gentoo
2006-10-31 11:48 "Split GNAT compilers" in Gentoo Ludovic Brenta
@ 2006-10-31 22:33 ` george
0 siblings, 0 replies; 2+ messages in thread
From: george @ 2006-10-31 22:33 UTC (permalink / raw)
Well, I think I mentioned this shortly once here already, but at that
time it was in a long thread on some hot topic :). So, I'll try to
elaborate. Brace yourself though - it is not going to be short.
Ludovic Brenta wrote:
> Could you please elaborate on this? I understand how you can install
> several versions side by side, but what do you mean by "split[ting]"
> the compilers?
>What is the impact on libraries? Also, could you explain
> why you need a "transition", i.e. what is the current state in Gentoo?
I'll start with the past situation with gnat in Gentoo, which was
pretty straightforward. We had gnat-3.15p and some work was done on
newer gnat versions. However, even though some were added to the tree,
they were not considered "stable". Incidentally this was during the
period of Ada "stagnation" - when FSF did not yet pick up on active Ada
maintainership. Correspondingly single gnat package was enough and the
libs could be built against it in a normal manner, pretty much the way
you have it in Debian. Later, when I picked up Ada maintainership again
(after the developer I recruited has gone MIA :), at least on Ada
packages) the situation with gnat was much better - FSF was issuing
working and frequently updated versions and ACT just produced
gnat-2005. Therefore I took a plunge and decided to implement the idea
we have been discussing for a long time before, - automating parallel
installs of different gnats and making Ada libs play nicely with the
compilers.
Now I need to do a little explanation of a few features unique to
Gentoo.
The situation when we provide multiple major versions of some package
(meaning change in API, - being primarily "from source" we do not worry
about ABI as much) is not uncommon in Gentoo. In fact we have a well
established mechanism of dealing with different major versions of the
same package. We have a special SLOT variable tracking API version
which is taken into the consideration by our package manager, so all
the dependencies can be resolved correctly for the packages that depend
on a particular version of some lib (e.g. gtk1 vs gtk2 or kdelibs-3.4
vs kdelibs-3.5, etc). The package itself is installed in a way to avoid
collisions between different SLOTted variants (usually not an issue
with shared libs that are done right, but may require some installation
trickery for the packages providing executables or some data files)
and, if necessary, some switcher app is provided (nowadays this is
standardized via providing a new module for an eselect package). For
example we had a SLOTted gcc for ages now. To give you an idea, here is
an output of the query for the provided gcc versions:
[I] sys-devel/gcc
Available versions:
(2.95) [P]2.95.3-r9
(3.1) [P]3.1.1-r2
(3.2) [P]3.2.2 [P]3.2.3-r4
(3.3) [P]3.3.2-r7 [P]3.3.5-r1 [P]3.3.5.20050130-r1 [P]3.3.6
[P]3.3.6-r1
(3.4) [P]3.4.1-r3 3.4.4-r1 3.4.5 3.4.5-r1 3.4.6 3.4.6-r1
3.4.6-r2
(4.0) *4.0.2-r3 *4.0.3
(4.1) 4.1.0-r1 4.1.1 4.1.1-r1
(4.2) [M]4.2.0_alpha20061014
The numbers in brackets are SLOT versions.
The situation with gnat was somewhat complicated by the fact that we
now have two upstream groups that provide gnat: ACT and FSF. Therefore,
upon discussing how to better package gnat, we decided to split it into
two packages: gnat-gcc for FSF's versions and gnat-gpl for ACT's. It is
possible to add more. For example, should ACT desire to have the
package for gnat-pro we can add it to the tree (since we do not
distribute binaries - strictly speaking we only provide installation
instructions, - we have the ability to provide ebuilds for commercial
packages (there are mechanisms to restrict access to sources (force
manual download) or just mirroring)).
When I was speaking about "split" I was primarily referring to this
situation, however this is only half of the story. The other half (and
the one really requiring "transition") concerns how the Ada libs are
dealt with. Apparently, having the ability to switch gnat compiler on
the fly is great of itself, however this can screw your compiled libs
if you just keep the original ebuilds. To resolve this situation I
created gnat.eclass (eclasses are our way to do OOP in bash :)) that
handles all the major parts of lib installation. Basically libs are
compiled for all the installed gnats (different SLOTs or variants, thus
if you have gnat-gcc-3.4.6, gnat-gcc-4.1.1 and gnat-gpl-3.4.6.2006
installed you will get your lib compiled three times) and then binaries
are put in a SLOT/gnat name regulated locations. Common files (sourced,
docs, etc) are of coruse shared. The same eselect-gnat module that
switches compilers also activates the corresponding version of the
libs. Thus you have a consistent system at any point in time (as long
as you use Gentoo provided tools of course) but can easily switch
between the installed variants. One "exception" is asis - it is buit
once for a corresponding compiler only and is installed at the compiler
location.
Now I am at the point of having transitioned the compilers, asis and
roughly half of the libs (packages under dev-ada category). I still
need to finish the few libs that are left.. There is also one
unresolved (well, postponed but that needs eventual resolution) issue.
Looks like we even have it easy with Ada, as compared to other
languages. You may take a look at this bug if you are interested:
https://bugs.gentoo.org/show_bug.cgi?id=151343
I would like to hear any input you may be willing to provide ;).
> Also, what in your opinion is the benefit of being able to switch
> compilers on the fly if they're binary-incompatible?
The binary incompatibility is taken care of as described above, now on
to the benefits :).
The most obvious one (to me at least) is "following the Gentoo spirit"
- that is providing as much choice as practical. You can quickly test
various compilers (given general adherence to ARM of Ada packages it
even may be possible to add non-gnat compilers to this mix) and how the
libs behave when built with, say, gnat-gcc-4.1.1 vs
gnat-gpl-3.4.6.2006. Now that the infrastructure is in place you can
even easily create the ebuild for your own package and enjoy this
automation.
Ok, this is already quite long, so I'll stop here. You may also take a
look at
https://bugs.gentoo.org/show_bug.cgi?id=111340
this is the bug where most of the design discussion took place. Beware
- it is quite a bit longer than even this description :).
George
PS
Oh, one more thing (to avoid possible misconceptions). That long list
of different gcc SLOTs I cited above does not mean that you can mix and
match gcc version like the gnat ones - there is no Gentoo-wide setup
like I just described for gnat (and it would not make sense
system-wide). So, practically speaking with gcc you do have the
flexibility of building your system with any of them, but you pretty
much have to stick to a particular version. Although you *can*
occasionally use some other version for a particular package.
PPS
This grew rather long and may be considered specialized. I wander if we
should take this discussion elsewhere (mentioned Gentoo bugs? if you
are interested) or is this issue interesting to the other as well?
Also, if anybody wants to chat in real time about any of these issues I
can be found on irc.freenode.net in channels #gentoo, #gentoo-dev and
few others. My nick there is georges.
^ permalink raw reply [flat|nested] 2+ messages in thread