From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5338f0adba025afb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!f16g2000cwb.googlegroups.com!not-for-mail From: george@gentoo.org Newsgroups: comp.lang.ada Subject: Re: "Split GNAT compilers" in Gentoo Date: 31 Oct 2006 14:33:11 -0800 Organization: http://groups.google.com Message-ID: <1162333991.590971.128020@f16g2000cwb.googlegroups.com> References: <1162295283.328548.222010@e64g2000cwd.googlegroups.com> NNTP-Posting-Host: 85.218.15.68 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1162333998 9936 127.0.0.1 (31 Oct 2006 22:33:18 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 31 Oct 2006 22:33:18 +0000 (UTC) User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; appLanguage) AppleWebKit/125.5.5 (KHTML, like Gecko) Safari/125.11,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: f16g2000cwb.googlegroups.com; posting-host=85.218.15.68; posting-account=Rd6r_Q0AAAA6EEVQqsubWwcFg5gPo_o3 Xref: g2news2.google.com comp.lang.ada:7311 Date: 2006-10-31T14:33:11-08:00 List-Id: 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.