As #111340 grew extremely long, and especially since the original issue of that bug is long resolved I am opening this one to serve as a tracker of all-things Ada related to new structure. Please open separate bugs for the end-point reorg issues (normal bugs - e.g. some package breaks, should not block it! They are visible for what they are anyway). In particular, if there are any structural issues to discuss or implement, what packages should still be ported.. Thus I am marking 111340 as a dependency. George
Hi George. I would like to know whether you have already decided on the issue that has been discussed in comments #96 and #97 from bug #111340 (which this bug depends on). Besides what is there discussed I would like you, please, to pay attention to another fact that has happened to me and that it speaks in favour to the adoption of the "keep the present profile active" (gcc-like behaviour). Before you provided the newest gnat-gpl-3.4.6 I had installed both gnat-gpl-3.4.5 and gnat-gcc-4.1 and set this latest compiler as the active one. My only reason behind installing gnat-gpl releases is just to check if they work and eventually reporting bugs, while I normally use the latest gnat-gcc for learning and production. Some weeks ago an unattended "emerge -vu world" installed the newest gnat-gpl-3.4.6 and set the active compiler to be that one. I forgot I still had the old gnat-gpl-3.4.5 in the production machine where I usually delete it after checking it succeeding in compiling a bunch of Ada libraries. The result is that I have been working with gnat-gpl-3.4.6 instead of gnat-gcc-4.1 for weeks until yesterday when I discovered that. Fortunatelly I also found out that the simple code I had sent to an italian magazine, that is publishing an article of mine on the Ada language with some illustrative programs, is able to compile with gnat-gcc-4.1 too as I had reported in the same article. fabio
Hm, looks like I did not respond here, while I seem to remember that I did. Probably that was to that other bug. Actually yes, see comment #114 in bug #111340 :). Anyway - the issue is resolved now. George
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=799693623d76c89e8b04d2434d0dfece44bb49f9 commit 799693623d76c89e8b04d2434d0dfece44bb49f9 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-08-03 02:27:51 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-09-29 00:18:08 +0000 toolchain.eclass: Ada rework Look hard for an existing GNAT for use for bootstrapping without requiring users to run `gcc-config` / switch their system copy of GCC, which is both brittle in that it requires manual intervention, and also unclean. Started looking at this after https://public-inbox.gentoo.org/gentoo-dev/2a700166-f01a-4807-bd76-7b0cce72af0b@archeia.com/ although the approach is different. I did use it as a base although not much of it remains. We take the following approach: * Iterate over installed GCC slots (preferring ${SLOT}, then iterating from the latest version installed down to GCC 10) to find a copy of GNAT; * Create wrappers for gnat* to redirect calls when building GCC to our found bootstrap copy of GNAT; * Use an extracted spec file to redirect gnat1 calls to that bootstrap copy too, as the build system doesn't allow saying "just use this copy of gnat" (it always wants $(CC) to support it). The real nasty part here is that GCC's build system doesn't seem to have a way to point to 'ADACC' or similar (it looks like it did have 'ADAC' years ago). Remaining bits to be done: * Adapting/replacing/supplementing dev-lang/gnat-gpl with a version that can be installed in parallel to sys-devel/gcc:10 so it can be pulled in transparently for bootstrapping; * Build our own, or source some other copy (e.g. from Alire), of a newer bootstrap GNAT. https://github.com/alire-project/GNAT-FSF-builds is a likely candidate. I also hope that we can ultimately do the same for D. Bug: https://gcc.gnu.org/PR864 Bug: https://gcc.gnu.org/PR108909 Bug: https://bugs.gentoo.org/137268 Bug: https://bugs.gentoo.org/547358 Bug: https://bugs.gentoo.org/919667 Closes: https://bugs.gentoo.org/937774 Link: https://lists.fedorahosted.org/archives/list/epel-devel@lists.fedoraproject.org/thread/CVQ3JIOZI5ODYDZU2DZLA37JWSLMCIN7/ Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 143 +++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 141 insertions(+), 2 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f210bb3d7324b1a6c1fe9d5e98cdfd57241d6499 commit f210bb3d7324b1a6c1fe9d5e98cdfd57241d6499 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-09-28 23:00:54 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-09-29 00:15:58 +0000 dev-lang/gnat-gpl: rename USE=bootstrap -> USE=system-bootstrap, invert meaning USE=bootstrap has/had a special meaning in <EAPI 5 and it also ends up stable-masked apparently too. It was dropped from use.desc in af748c0468c6ab3ce760de2bfd84f4cef1eb9bcf and dropped from sys-devel/gcc a while ago too (bug #440224). To facilitate automatically using gnat-gpl in sys-devel/gcc, do two things: * Rename USE=bootstrap -> USE=system-bootstrap * Make USE=system-bootstrap mean "I need a working Ada compiler to build this" (i.e. invert its meaning) to match dev-java/openjdk and dev-lang/rust. Bug: https://bugs.gentoo.org/137268 Bug: https://bugs.gentoo.org/440224 Bug: https://bugs.gentoo.org/547358 Bug: https://bugs.gentoo.org/919667 Signed-off-by: Sam James <sam@gentoo.org> dev-lang/gnat-gpl/gnat-gpl-2021-r5.ebuild | 12 ++++++------ dev-lang/gnat-gpl/metadata.xml | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-)
