At the irc discussion with dcoutts today the issue has come up that we put aside for Ada, but that seems more severe in Haskell case. That is if you have one lib depend on another, when you install compilers you may get emerges of the libs fail, when eclass attempts to emerge the lib that depends on another that was not built for the now-present compiler. In our case, having may be the whole one incidence of such dependency (gtkada on xmlada IIRC) it was not really an issue at this stage yet. But if we keep adding more stuff to the tree we may facethis problem as well (for example GPS is not transitioned to new system yet. When it is, we may start facing this problem for real). The fully flexible resolution will likely require support from portage, which is unrealistic to expect to happen in foreseeable future. Here I will describe the simplified alternative, which I think should work and be easy to implement. Basically we will require the user to pick his collection of "primary" compilers and list them in some file. Something like gnat-gpl-3.4, gnat-gcc-4.1. I think about requiring both name and a SLOT info in that list - otherwise stuff will break when new slot of some compiler comes alive. Then the eclass gets modified to 1. Enforce that some version of selected compiler-SLOT combination is already emerged - for every such entry on the list 2. Emerges the selected package for all the compilers on the list. Originally I had "and only for the ones on the list" there, but now I think we may have some option selecting whether to restrict libs to be built only for the "primary" compilers or allow them to be built for all installed.. Another note: this really only concerns the libs, as final executables that do not really care with what lib they were built, as long as it is available, do not need to use gnat.eclass. George
On more remark. There is a straightforward way of dealing with this situation of multiple compilers. That is to split lib packages. But this quickly becomes a mess with lots of duplicated code, as one has more and more compilers. One way to avoid code duplication would be to introduce eclasses, but that would pretty much mean one eclass per (original, nonsplit) package, which is only sensible if we had per-category eclasses or something like that :). George
Sounds like this issue is related to issues on multilib systems (where libraries are compiled for different ABIs on the same system). There are various approaches for this in toolchain; one is to build for all ABIs (which means the existing atoms/dependencies don't change; changes to portage are relatively simple), another is to add ABI information to the dependencies (which obviously requires a change to the portage EABI). One special case is sys-libs/glibc which does some trickery in its ebuild to get the library built for all ABIs. Note also that in the main toolchain, switching ABIs is a matter of supplying the right switches to the compiler. I don't suppose gnat-4.x can be told to generate for the gnat-3.x ABI? Is that what this issue is? I.e. has the ABI changed between versions of the compiler such that libraries built with different versions of the compiler are incompatible? If so, perhaps it would be a good idea to bring in people working on multiple ABI systems from toolchain. It would be sensible to try to have a similar approach for both.
Yes, the issue is indeed the incompatible ABIs, with the difference being, as you outlined, that we cannot simply set some flags, but rather need to run eselect gnat set to switch compilers.. I agree that it makes sense to bring in the people from toolchain. I added toolchain@g.o to CC, is anything else necessary? toolchain people: Please take a look. It looks like we are facing a common problem here, so we may as well produce a common solution :). You can look at #111340 for more details on Ada particulars if you wish, just beware, it is long. It even may be more sensible to read it somewhat backwards.. George
(In reply to comment #2) > Is that what this issue is? I.e. has the ABI changed between versions of the > compiler such that libraries built with different versions of the compiler are > incompatible? I can't speak for ADA folk, but it's exactly the issue that other languages face, eg Python and GHC are not ABI compatible between different major versions. That is the libs are not compatible (though upstream have considered this issue so they are parallel installable for different compiler versions). > If so, perhaps it would be a good idea to bring in people working on multiple > ABI systems from toolchain. It would be sensible to try to have a similar > approach for both. That'd be great. Unlike arch ABIs, we're using different compiler versions so we can't always guarantee that each package will build for every installed version of the compiler. So I think we have to deal with actually keeping track of which compiler versions a lib is slotted on. Fortunately portage now has slot deps which I expect will be part of the solution. SLOT="${PV}-${ABI}" DEPEND="dev-thing/foo-1.0 : ${ABI}" the problem here of course is that ABI can't be a normal var since it's not a constant a cache generation time. But you get the idea, this is the sort of thing I've been imagining.
So, this is not such a hot topic after all? Upon updating some libs I realized we have more than singular cross-dependency. As it stands now: adadoc -> xmlada gps -> gtkada adaopengl -> adabindx Still not that many, but nonetheless this makes me think about actually adding the guarding mechanism that I described in the opening comment. One more detail - I though about list (of "primary" compiler) location. I think it makes sence to track it unde /etc, something like /etc/ada/primary-compilers. George
For the lack of other proposals I will go ahead with what I described in the opening comment. However the solution will have to be enhanced, since now we are starting to see Ada-2005 compilers coming out and some libs start to require that version and, correspondingly, will have to be built for a subset of primary compilers. Here is how it stands as of now: 1. Some compilers are designated as primary. All the libs using gant.eclass are built for these compilers only. Other compilers that are installed but are not on the list are considered "trial" and are not used to build the libs. 2. The "list" actually consists of multiple files, - one for each version of Ada standard that for which we have compilers. Right now that would be two: ada-1995 and ada-2005. Good location to keep these files seems to be a directory (instead of a single file, as was proposed before) /etc/ada/primary-compilers/. This is selected to be under /etc since this is supposed to be user-configurable. 3. Final touch, to make dependencies consistent and pull in the right compiler if user decides to emerge, say, qtada directly. A new virtual: virtual/ada will be introduced. virtual/gnat is used right now to track compiler backends and this one will be used to track standard versions. Comments, problems? I'll try to get around to actually implementing this some time soon I hope :). George
So, I finally implemented this enhancement. It actually went better than I expected. Final setup, as it got implemented: 1. Primary compilers 1.1 There is only one list for users to edit - /etc/ada/primary_compilers, which simply contains gnat profiles that user want to regularly use listed one per line. For example mine at the moment contains: $ cat /etc/ada/primary_compilers x86_64-pc-linux-gnu-gnat-gcc-4.2 x86_64-pc-linux-gnu-gnat-gpl-4.1 1.2. The lib_compile and lib_install functions are now looped only over the installed compilers on that list, not all as before. Nice prat is that this did not require much code changes, in fact very minor - replacing one function call (find_compilers with find_primary_compilers) and, naturally, implementing that function (an ~ 3-liner). 1.3. Added a check to gnat_pkg_setup to verify that all requested primary compilers are in fact installed (to avoid problems with dependencies, as discussed in the opening of the bug) - this was one of the principal driving forces behind doing this whole thing after all.. 2. Depending on a particular Ada standard 2.1 virtual/ada has been added to track Ada standard variants. Right now it contains ada-1995 and ada-2005. Last one only has ...-gnat-gpl-4.1, however gnat-gcc-4.3 may be added soon, depending on whether qtada will build with it when it gets released (this is the most Ada-2005 demanding package atm) 2.2 ebuilds simply specify the required dependency on virtual/ada or virtual/ada-2005, etc. as usual and gnat.eclass takes care of the rest (that is further reducing the list of considered compilers with which the lib gets built) Everything seems to work fine so far. However users need to be notified of the following change: Now it is necessary to modify the /etc/ada/primary_compilers file and list there all but only those gnat compilers that are intended for regular use. Compilers not listed in that file will not be used for building libs, however may be activated and used transiently as usual. To provide some basic "protection" the first gnat installation populates the file with its own profile, to make sure users have something in there and lib emerges do not just fail. Hand-editing is nonetheless necessary "for best results". As far as I am concerned all the issues raised in this bug have been resolved as of now, so, considering that there was not much activity otherwise, I am going to close it. George
