Re: ASIS, coinstall gnat-10 and 11, deprecate gnatgcc
Le 12/07/2022 à 02:57, Ludovic Brenta a écrit : ISTR that AdaControl does not require the tree files of units that are not the ones being analyzed. More precisely, the tree file of a unit contains the trees of the specifications of all the "withed" units, i.e. it stands by itself. That's why ASIS keeps only one tree file... and has to do the infamous "tree swapping" when moving from the specification to the body of a unit. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52 https://www.adalog.fr
Re: ASIS, coinstall gnat-10 and 11, deprecate gnatgcc
On 2022-07-12 04:57, Ludovic Brenta wrote: I suggest that all people who want ASIS in Debian step up to this challenge. I am in, however, the proper way to get ASIS for Ada is be to make a libadalang implementation of ASIS interfaces, and we would be glad to contribute in this way. An important step for the Ada community (and related to the present discussion) is also to build a common vision on the future of the ASIS standard. @AdaLabs we ported our Morpheus engine (a code analysis and refactoring framework) from ASIS to libadalang successfully, and we also find the libadalang interface more attractive. Code generation is an important step to be able to increase COTS maintenance efficiency, and libadalang also achieved this goal in a very interesting way.
Re: ASIS, coinstall gnat-10 and 11, deprecate gnatgcc
Stephane Carrez writes: > Having a gnat-10 and gnat-11 package can bring confusion to users. Most Ada > libraries > will be targeted at gnat-11 and they won't work with gnat-10. Agreed. > Then, what about providing an asis-gcc package that only provides the > gcc+gnat compiler > renamed to whatever we want to fit the asis implementation as suggested by JP. Nicolas tries to leverage the existing work that was done to package gcc-10, which seems the obvious thing to do. But for ASIS we don't need any cross-compilation targets, we don't need any language besides Ada, and we don't want to find that the Debian GCC maintainers want to remove gcc-10 from Debian (which they will do, eventually). So, like Stéphane I think the solution is proper packaging of a minimal asis-gcc that we control, that can only produce tree files and not object files (and I suspect asis-tools from GNAT Pro is just that, in fact). This packaging and future maintenance is quite a big thing and I don't expect Nicolas to do it on his own. I suggest that all people who want ASIS in Debian step up to this challenge. > One point that is not clear for me concerns the Ada libraries that such > compiler/tree > generator would access. By "Ada libraries" I assume you mean "Debian packages providing precompiled Ada libraries", because if you mean "source files installed in the user's $HOME directory" then Debian has no control over them. The "asis-gcc" compiler/tree generator would access the same library source files as the gnat-11 compiler. However the Library_ALI_Dir and Library_Dir declared in the .gpr file for the library belong to a Debian package, and to the root user, and they do not contain any tree files. Also, all the precompiled libraries from Debian packages declare that they are Externally_Built. Therefore, if someone wants to recompile their program and the libraries with asis-gcc (or gnat-10 or whatever it is called), they will have to recompile everything into their own build directory, under $HOME. I suspect they might have to write their own project file for this. But perhaps we can assume that developers are not interested in analyzing the conformance of Debian packages to AdaControl rules, so they are not interested in recompiling libraries from Debian packages. They are only interested in recompiling their own source files (that use said precompiled libraries). ISTR that AdaControl does not require the tree files of units that are not the ones being analyzed. This simplifies the problem. If Debian can solve this simpler problem, then I think we can declare victory. > If we compile with gcc-11 and run asis with a gcc-10, will it have access to > the same Ada > libraries? You need to be specific about which *files* they will look for and ask your question more precisely. Similarly, "we run asis with a gcc-10" really means "we recompile some source files with gcc-10 to produce tree files". -- Ludovic Brenta.
Re: ASIS, coinstall gnat-10 and 11, deprecate gnatgcc
Hi! On 11/07/2022 15:12, Nicolas Boulenguez wrote: 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. Having a gnat-10 and gnat-11 package can bring confusion to users. Most Ada libraries will be targeted at gnat-11 and they won't work with gnat-10. Then, what about providing an asis-gcc package that only provides the gcc+gnat compiler renamed to whatever we want to fit the asis implementation as suggested by JP. One point that is not clear for me concerns the Ada libraries that such compiler/tree generator would access. If we compile with gcc-11 and run asis with a gcc-10, will it have access to the same Ada libraries? Stephane
Re: ASIS, coinstall gnat-10 and 11, deprecate gnatgcc
Le 11/07/2022 à 15:12, Nicolas Boulenguez a écrit : 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. FWIW, AdaControl can use any "tree generator", even if it is not named "gcc". The default path to the tree generator is defined by a constant, at implementation_options.adb:102. You can change this to whatever is convenient for Debian... HTH. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52 https://www.adalog.fr
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=8
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.
