gnatbuild.eclass loosely follows toolchain.eclass. The original version was crete over 10 years ago with mostly changes to the gnat-specific logic ever since. However, over this time bunch og gcc-internals relted things have changed. It has been difficult to issue a major update for quite a while already, and now we are at the point where even everyday function is broken due to underlying changes in gcc. See, e.g., #501178, but I'll start marking dependencies on this bug, there should be plenty.. It seems enough crust has accumulated over all this time, so the inevitable cannot be postponed anymore. The gnatbuild.eclass has to be overhauled to follow toolchain.eclass more closely again. As this seems to be a rather major change, potentially introducing bunch of USE flags from gcc too, I think it is better to go about it in stages. Here are the principal steps palnned: 1. create a new gnatbuild2.eclass, following toolchain and merging in gnat-specific stuff.. (at the moment seems easier than the other way around) 2. migrate gnat-gcc/gnat-gpl ebuilds to use this new class one by one 3. (optional) once the migration is over, remove old eclass, rename gnatbuild2 to old name and adjust ebuilds again. The 3 is optional - would prevent spillage of obsolete eclasses and should be well contained (all the affected ebuilds are under dev-lang/gnat-{gcc,gpl}), so it seems useful, but both eclasses could be kept to provide some kind of tracking if this is preferred.. PS Hm, looking for an option to assign this bug directly to ada at creation - I seem to remember seeing this option before, but cannot find it now. I guess I'll have to do it after submitting the bug. To bugwranglers: please assign this to ada@gentoo.org directly if you catch it before I do this myself.
reassigning the bug to ada team
(In reply to George Shapovalov from comment #0) > Hm, looking for an option to assign this bug directly to ada at creation - I > seem to remember seeing this option before, but cannot find it now. There's a link called 'Show Advanced Fields'.
Umm, maybe this is halfway-to-most-of-the-way there? Pretty much out of my hieny I've pulled a gnat-r1.eclass and made some new (and larger) gnatboot tarballs and bumped gnat-gcc to 4.9.3 along with minor updates to eselect-gnat and a bigger/recent change on the package side (made a new gnat-r1.eclass and tested a modified ncurses with use=ada (the latter is not yet pushed due to working on gnat-r1 and related policy changes). I wrote up some draft policy stuff in the gnat-r1.eclass comments so lemme push that to my overlay for now.
What's the schedule of getting this into portage?
The packaging/policy details are still TBD but we're testing the replacement for separate gnat ebuilds right now. Meaning "USE=ada emerge gcc" is now working with slightly modified eclass/packages; see the ada-overlay: https://github.com/sarnold/ada-overlay I haven't synced my latest fixes with Luke yet, so try the above for now. So gnatbuild.eclass will be going away, but there still needs to be some kind of ebuild helper (which is not updated yet beyond the drafty gnat-r1.eclass). Looking good so far, but the new toolchain.ecalss still needs a few tweaks/fixes.
Hi Steve, Former Ada maintainer here:). Nice to see it was not completely forgotten! (And sorry for dropping out, but real life takes over at certain point, so I could not keep up with the upstream changes of last few years..) I tried to emerge gnat - this is the in-tree one, but I cannot find a more appropriate bug for this. But please tell me if you prefer I create a new bug for this. Below a few points: 1. So, I see that gnat-gcc was pulled, only gnat-gpl is left, which is logical at this point as AdaCore version have finally caught up backend-wise. So, no need for two compilers in-tree any more. This simplifies the build and handling.. However, 2. As I see the principle idea is that Ada support will be integrated into gcc itself? This was considered before, but it was decided against back then because: 2.1. Proper integration with "main upstream source" (AdaCore) was not as smooth and would require significant changes to the backend. So, did the situation improve enough or are you considering integrating only FSF version in gcc? 2.2. Another argument was that building gnat requires Ada-enabled gcc and far from everybody would want a bloated gcc by default (and more importantly, if you disable Ada even once, you cannot rebuild it - if you keep to system-gcc only). But this can be fixed by pulling a bootstrap gcc "superset", as is done now for gnat-gpl. So this one is minor.. 3. The essential one. After emerging gnat-gpl and enabling corresponding gcc profile with gcc-config (and running . /etc/profile of course) I tried emerging gprbuild. It demanded that I enable exactly-one-of ( gnat_2016 gnat_2017 ). I then looked up the gnat flags and saw those two used all over the Ada-related libs. So, as I understand, you use those two flags as a stand-in SLOT-like feature? Only you don't provide multiple slots here and instead force the user to one version only.. While losing the ability to switch profiles on the fly is debatable in itself (I agree that simplifying the system is well worth the inconvenience), but I question the maintenance angle - basically its another (and not totally trivial thing) to keep track of during (annual or even more frequent) update whenever new major version comes out. With gnat decoupled from gcc it can be somewhat mitigated, but with Ada-enable gcc it may get messy.. Just ti note here, that the major part of that code in gnatbuild.eclass and former gnat.eclss (now pulled) was providing this functionality - multiple profiles (a-la multilib) with possibility to switch them on the fly. And that concerned not only switching between gnat-gpl and gnat-gcc - the switch could be made from any SLOT of either compiler to any other compiler:SLOT. That is to say - that code applied to the present situation (SLOTted gnat-gpl) just as well as for switching between different compilers. I do understand that keeping or reimplementing such functionality would go against the paradigm of integrating Ada directly into gcc. However I would argue that a more elegant mechanism could be useful even in this case (as users are guaranteed to forget to reset gnat_year flags and then complaint after any major update..) Thanks for your work and good luck with getting it all done! George
Just a short thought on those USE flags - IMHO it would be much less cumbersome (and more telling) to version them using the GCC_MAJOR instead of a year (like gnat_46 and gnat_63 or whatever ${GCC_MAJOR} reports) - easier to automate too. Besides, you are guaranteed to have multiple major updates in the same year at some point :).
A few final thoughts on the last point of my longish post: Integrating gnat with gcc does not contradict multiple gnat profiles (libs built for multiple gnat/gcc SLOTs in parallel) - it *can* be done, in the similar way to how it was done before. Whether to actually provide and support that functionality is, definitely, up to maintainer :). As for the "more elegant mechanism" of enforcing consistency (or providing multiple profiles - this can do both): it makes sense to just follow the suite with python, Ruby and others and provide vars controlling what gets buil or is used. Like: ADA_SINGLE_TARGET to enforce which gnat/gcc major version is active/in use - only this var is needed in case of enforcing single profile, or together with: ADA_TARGETS - in case of multiple profiles/SLOTs. The rationale here is the same as for e.g. python - to make it harder for end user to screw up (e.g. by emerging one lib, then changing USE and emerging other libs). The detailed control is still possible via per-package keywords, but screwing up now requires explicit extra effort by end user. The implementation detail may actually be different, but at least this provides an already familiar interface..
Hey, its been a while, and I totally understand no reaction - Ada is a beast :). Writing now to mention that I started using Ada again for my work, so I am even considering to retake over the maintainership of it again.. First, of course, I need to get up to speed (and dig more into the toolchain magic). Speaking of which, I was looking through the toolchan.eclass in the Ada overlay, and stumbled upon this: @@ -364,6 +395,14 @@ + # TODO: Add bootstraps for arm64/mips/ppc/other arches. + if in_iuse ada; then + GCC_SRC_URI+=" amd64? ( https://dev.gentoo.org/~nerdboy/files/gnatboot-${GNAT_BOOTSTRAP_VERSION}-amd64.tar.xz ) [.. bunch of other SRC_URIs stripped] + fi Is this actually legal/can this be done? I remember big flaming discussion of this matted on -dev list with grand conclusion that SCR_URI shall not depend on USE flags, infra and mirrors were quite against being screwed over by dynamic file lists to be synced. But yes, this was years ago. Has this changed since then?
eclass was removed
