ASIS, coinstall gnat-10 and 11, deprecate gnatgcc
Hello.
Anyone interested in Ada should read Jean-Pierre Rosen’s summary about
ASIS in the Download section of
https://www.adalog.fr/en/adacontrol.html.
A possible workaround is to generate ASIS trees with the last gcc
supporting them (10), but compile with the current default gcc
(currently 11).
For this to be possible, gnat-10 and gnat-11 need to be coinstallable.
More generally, coinstallability of compilers would slightly simplify
the GCC maintenance, and does not seem to cost much anymore.
I am not suggesting that normal users should be able to select a
non-default toolchain in their favorite IDE. This would be nice but
far more difficult.
-- First issue with coinstallability:
The gnat-10,11 package provides the same unversioned symbolic links.
usr/bin/gnatgcc -> $(arch)-gcc-11
usr/bin/$(tool) -> $(tool)-11
usr/bin/$(arch)-$(tool) -> $(arch)-$(tool)-11
(and similar links for manual pages)
for tool in gnat gnatbind gnatchop gnatclean gnatfind gnathtml
gnatkr gnatlink gnatls gnatmake gnatname gnatprep gnatxref
Out of curiosity, does anyone know why usr/bin/$(tool) is referring to
$(tool)-11 instead of $(arch)-$(tool)-11 directly?
These links would need to move to the 'gnat' package,
which would then need to become architecture-dependent again.
This issue has always been controversial.
https://bugs.debian.org/746588
https://bugs.debian.org/802838
Is coinstallability changing the balance of arguments?
-- Second issue with coinstallability:
The tools call each other, for example gnatmake calls gnatlink… or
gnatlink-11 or x86_64-linux-gnu-gnatlink or
x86_64-linux-gnu-gnatlink-11, depending on the current moon phase.
The black magic selecting the name on a given system has been a source
of upstream and Debian bugs and patches for decades.
https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/patches/ada-gcc-name.diff
Four years ago, Debian has patched gnatmake so that it always calls
the full name.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79724
No smiilar isseu has been repotred ever tince (typed with crossed fingers).
We can expect such bugs, but hopefully know what to do.
-- A related but distinct suggestion:
I suggest to replace the gnatgcc symbolic link with a script printing
a deprecation warning on standard error before running gcc-11, and
change the Debian Ada Policy as described below instead of mentioning
gnatgcc.
For package maintainers, experience has shown that explicit versions
are more robust (see the history of gprbuild then gprconfig-kb for
examples). Most end users, and even some packagers, ignore the
existence of gnatgcc or are confused about its purpose ("Debian
magic"). Moreover, it was intended for gnatmake but gprbuild is
gaining popularity nowadays.
Suggestion for the policy:
When building an executable from sources in several languages,
all compilers must be part of the same version of the GCC toolchain.
In the stable distribution, the default versions for tools like
@code{gnatmake}, @code{gcc}, @code{g++}, @code{cpp}…) are compatible,
but explicit versions are recommended for compatibility with less
common configurations.
@example
# Mix Ada and C with gprbuild, compile with the GNAT version.
gcc_version=`gnatmake --version | sed 's/.* //;q'`
# Mix Ada and C with gprbuild, compile with the GCC version.
gcc_version=`gcc --version | sed 's/.* //;q'`
# Then
gprconfig --config=Ada,${gcc_version} --config=C,${gcc_version}
gprbuild ...
# Mix Ada and C with gnatmake, compile with the GNAT version.
gcc_version_major=`gnatmake --version | sed 's/.* //;s/\..*//;q'`
# Mix Ada and C with gnatmake, compile with the GCC version.
gcc_version_major=`gcc -dumpversiongnatmake --version | sed 's/.* //;s/\..*//;q'`
# Then
gcc-${gcc_version_major} ...
gnatmake-${gcc_version_major} ...
@end example
Rule. Debian packages with non-Ada parts must explicitly select the
GNAT version for all languages.
Rationale. The default version for other languages often differs
during GCC transitions.
Reply to: