Re: One united Ada policy for all Linux distributions?

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Dmitry A. Kazakov wrote on comp.lang.ada:
> On Tue, 18 May 2010 03:19:36 -0700 (PDT), Ludovic Brenta wrote:
>> Dmitry A. Kazakov wrote on comp.lang.ada:
>>> If we wanted to introduce versioning (coexistence in Debian policy terms?),
>>> we could hang version suffixes on the gpr's directory, rather than on gpr
>>> files. The suffix will follow GNAT releases.
>
>> That would be too restrictive; it would not allow you to have e.g. two
>> versions of a library with the same compiler.
>
> Why? Each GNAT (gnatmake, gprbuild) would search its project directory
> first. It should be no different from the way the standard library ads
> files are handled - transparently to the user.

In both Debian and GNAT GPL Edition, you can actually choose between
two versions of the standard library: zero-cost and setjump/longjump.
But that aside, the standard library is tightly coupled to the
compiler, so it makes sense to install it in a compiler-dependent
location. On the contrary, third-party libraries are *not* tightly
coupled to the compiler, have different release cycles, and should
therefore *not* be in a compiler-dependent location. It is a bad idea
to artificially tie some version of a third-party library with some
version of the compiler.

>> This is no better than
>> the GNAT GPL distribution as you noted.  So the versioning would have
>> to use the aliversion in the names of the .gpr files, possibly with a
>> versionless symlink to the default versioned project file, e.g.:
>
>> /usr/share/ada/adainclude/gtkada2.14.2.gpr
>> /usr/share/ada/adainclude/gtkada2.18.gpr
>> /usr/share/ada/adainclude/gtkada.gpr -> gtkada2.14.2.gpr
>
> That would mean version-dependent gpr files. This is what we have now. BTW,
> it probably won't work, because the project name is checked against the
> file name.
>
> The idea is that the name of a gpr file never changes, so you do not need
> to modify your gpr file each time a new gtkada version comes. You don't
> need to modify it for another Linux.

Ah but sometimes a new version of a library breaks source
compatibility with existing programs. Suppose that Debian and Fedora
both provide /usr/share/ada/adainclude/x.gpr; this file comes from the
package libx1-dev in Debian and from libx2-devel in Fedora. Suppose
that X version 1 and X version 2 are incompatible at the source level.
Your user program that compiles cleanly on Debian will not compile on
Fedora and vice versa. How would you propose to address this in a
"unified" policy? How do you propose to address this in your user-
written program?

--
Ludovic Brenta.