Prev: Call for papers: SETP-10, USA, July 2010
Next: TXL Grammar for Ada 2005
From: Ludovic Brenta on 18 May 2010 09:09
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.
From: Dmitry A. Kazakov on 18 May 2010 10:00
On Tue, 18 May 2010 06:09:25 -0700 (PDT), Ludovic Brenta wrote:

> 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.

Theoretically tue, but in practice *-dev packages depend on the compiler
package anyway. At least ALIs must be recompiled, otherwise GNAT will
complain. So I don't see it as an additional restriction.

>>> 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?

Isn't it to be resolved at the package level? If my package requires the
package x version 1 (but not x version 2), I should state this in
"Requires."

> How do you propose to address this in your user-
> written program?

When a new version of x comes, I must test against it and make a new
release for it, if necessary. 100% upward compatibility does not exist. as
we all know.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Björn Persson on 19 May 2010 09:23
Another difference, in addition to the ones Ludovic mentioned, is that the
Debian policy requires static libraries in the -dev packages, while Fedora
strongly discourages packaging static libraries and mandates that they be
kept in -static packages, separate from the dynamic libraries in the -devel
packages, if they really must be included.

Obviously we can't have one policy to rule them all, but we could certainly
talk to each other and try to be compatible enough that we don't cause
unnecessary trouble for users.

--
Bj�rn Persson
PGP key A88682FD
From: Björn Persson on 19 May 2010 09:24
Dmitry A. Kazakov wrote:

> Ideally gpr files should be installed where GPS,
> gprbuild, gnatmake could look after them. GNAT GPL's GPS does it in
> <GNAT-root>/lib/gnat. I think the policy should mandate a directory under
> /usr/lib or /usr/include for all gpr files rather than project-dependent
> directories.

The question of where to store .gpr files is actually rather complicated.
The .gpr file for a library needs to point to architecture-specific library
files, which makes the .gpr file itself architecture-specific if the
location is hard-coded. For example, a multilib system may have a 32-bit
/usr/lib/lib<library>.so with .ali files in /usr/lib/<library>/, and a 64-
bit /usr/lib64/lib<library>.so with .ali files in /usr/lib64/<library>/. It
would then need two different .gpr files, one pointing to /usr/lib/<library>
and the other to /usr/lib64/<library>. One might then try putting the .gpr
files somewhere in /usr/lib* too, for example /usr/lib/gnat/<library>.gpr
and /usr/lib64/gnat/<library>.gpr. That doesn't work however, because
although Gnat can be configured to look for .gpr files in multiple
directories, it will look in the same set of directories regardless of
whether it's compiling for 32-bit or 64-bit mode, and use the first .gpr
file with a matching name that it finds. If it finds the 64-bit
<library>.gpr first, then compiling 32-bit binaries fails, and vice versa.

To solve this problem in Fedora I parameterize the .gpr files. There is a
file named common.gpr which defines the variable Lib as either "lib" or
"lib64" depending on an environment variable named HARDWARE_PLATFORM.
HARDWARE_PLATFORM is defined by a snippet of shell script in
/etc/profile.d/, and can be changed with the command "setarch". All the
other .gpr files import common.gpr and use the variable Lib like this:

for Library_Dir use "/usr/" & Common.Lib;
for Library_ALI_Dir use "/usr/" & Common.Lib & "/<library>";

That makes the .gpr files architecture-independent. According to the
Filesystem Hierarchy Standard they should then be somewhere under
/usr/share. I keep them in /usr/lib/gnat however, because that's where Gnat
looks for them (but not in /usr/lib64/gnat, only in /usr/lib/gnat). This is
controlled by an RPM macro named _GNAT_project_dir, so if I were to move the
..gpr files I would only need to change the macro and rebuild the packages.

--
Bj�rn Persson
PGP key A88682FD
From: Dmitry A. Kazakov on 19 May 2010 10:13
On Wed, 19 May 2010 15:23:51 +0200, Bj�rn Persson wrote:

> Another difference, in addition to the ones Ludovic mentioned, is that the
> Debian policy requires static libraries in the -dev packages, while Fedora
> strongly discourages packaging static libraries and mandates that they be
> kept in -static packages, separate from the dynamic libraries in the -devel
> packages, if they really must be included.

Isn't Debian's dev = Fedora's devel?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Call for papers: SETP-10, USA, July 2010
Next: TXL Grammar for Ada 2005