Debian Policy for Ada, Second Edition

Debian Policy for Ada, Second Edition

[Ludovic Brenta]

After more than a year, I have just uploaded the second edition of the
Debian Policy for Ada.  It is now available on Ada-France's web site
as HTML, plain text, and PDF.  In addition, the Debian .deb package
contains an info version.

As I explained during the FOSDEM, the Policy itself has not changed.
Basically, it consist of two points: (1) all Ada packages must use the
same compiler from the gnat package, and (2) all libraries must follow
the GNU Ada Environment Specification for the filesystem structure,
and provide GNAT project files.

However, I have reworded most of the document for clarity, and updated
a lot of time-dependent information.  There are also details on the
planned transition to GCC 4.1 in Etch in an appendix.

http://www.ada-france.org/debian/
http://www.ada-france.org/debian/debian-ada-policy.html

And for your /etc/apt/sources.list, if you use Debian:

deb http://www.ada-france.org/debian/ ada main
deb-src deb http://www.ada-france.org/debian/ ada main

As always, I welcome comments and suggestions.

-- 
Ludovic Brenta.

Re: Debian Policy for Ada, Second Edition

[Pascal Obry]

Ludovic Brenta a �crit :

> As always, I welcome comments and suggestions.

I see that you recommend for libraries using :

/usr/share/ada/adainclude/ for sources.

/usr/lib/ for libraries

/usr/share/ada/adainclude/ for project files.

I think it would be far better to follow the GNAT default, this way
project files are found automatically by GNAT and there is no need to
set ADA_PROJECT_PATH at all for example.

Moreover XML/Ada, AWS, ASIS, PolyORB have been updated to use this
default install scheme and they all work together. And also if you
follow the default location for the documentation GPS will be able to
find them automatically and they will appear into the Help menu.

As I said I think it would be better to stick to the GNAT default setup.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Debian Policy for Ada, Second Edition

[Ludovic Brenta]

Pascal Obry <pascal@obry.net> writes:

> Ludovic Brenta a écrit :
>
>> As always, I welcome comments and suggestions.
>
> I see that you recommend for libraries using :
>
> /usr/share/ada/adainclude/ for sources.
>
> /usr/lib/ for libraries
>
> /usr/share/ada/adainclude/ for project files.

I am not aware of a GNAT default.  What is the default? And why does
it not follow the GNAE?

> I think it would be far better to follow the GNAT default, this way
> project files are found automatically by GNAT and there is no need to
> set ADA_PROJECT_PATH at all for example.
>
> Moreover XML/Ada, AWS, ASIS, PolyORB have been updated to use this
> default install scheme and they all work together. And also if you
> follow the default location for the documentation GPS will be able to
> find them automatically and they will appear into the Help menu.
>
> As I said I think it would be better to stick to the GNAT default setup.

Maybe symlinks can come to the rescue to provide interoperability.

-- 
Ludovic Brenta.

Re: Debian Policy for Ada, Second Edition

[Pascal Obry]

Ludovic Brenta a écrit :

> I am not aware of a GNAT default.  What is the default? And why does
> it not follow the GNAE?

To be able to install a compiler in its own directory and to be able to
have multiple compilers installed at the same time.

The scheme is something like:

/opt/GNAT/<ver>
  /bin                 <- binaries there
  /lib/gnat/           <- project files there (GNAT looks there)
  /lib/gnat/<project>  <- if needed sub-project files
  /lib/<project>       <- .o .ali .a .so for <project>
  /lib                 <- sym links to .a and .so above
  /include/<project>   <- .ads/.adb for <project>
  /share/doc/<project> <- documentation
  /share/gps/plug-ins  <- .xml for GPS customization (doc, tools)


> Maybe symlinks can come to the rescue to provide interoperability.

That will be lot of them and you won't be able to support multiple
compilers. But maybe this is not a requirement for Debian.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Debian Policy for Ada, Second Edition

[Ludovic Brenta]

Pascal Obry <pascal@obry.net> writes:
> Ludovic Brenta a écrit :
>
>> I am not aware of a GNAT default.  What is the default? And why does
>> it not follow the GNAE?
>
> To be able to install a compiler in its own directory and to be able to
> have multiple compilers installed at the same time.
>
> The scheme is something like:
>
> /opt/GNAT/<ver>
>   /bin                 <- binaries there
>   /lib/gnat/           <- project files there (GNAT looks there)
>   /lib/gnat/<project>  <- if needed sub-project files
>   /lib/<project>       <- .o .ali .a .so for <project>
>   /lib                 <- sym links to .a and .so above
>   /include/<project>   <- .ads/.adb for <project>
>   /share/doc/<project> <- documentation
>   /share/gps/plug-ins  <- .xml for GPS customization (doc, tools)
>
>
>> Maybe symlinks can come to the rescue to provide interoperability.
>
> That will be lot of them and you won't be able to support multiple
> compilers. But maybe this is not a requirement for Debian.

Indeed, the policy states clearly that exactly one compiler is
supported in Debian, so that all packages are ABI compatible.

The default project path is a new feature of GNAT that I was unaware
of; thanks for pointing it out to me.

I see that I can change the default by patching
src/gcc/ada/Make-lang.in, which generates build/gcc/ada/sdefault.adb.
I think I'll do that, thus making the symlinks unnecessary, and
allowing GNAT to find all libraries' project files automatically.

Objections?

-- 
Ludovic Brenta.

Re: Debian Policy for Ada, Second Edition

[Pascal Obry]

Ludovic Brenta a écrit :

> I see that I can change the default by patching
> src/gcc/ada/Make-lang.in, which generates build/gcc/ada/sdefault.adb.
> I think I'll do that, thus making the symlinks unnecessary, and
> allowing GNAT to find all libraries' project files automatically.
> 
> Objections?

This is some more maintenance work... but you are doing all the work ;)
so I have no objection.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Debian Policy for Ada, Second Edition

[Georg Bauhaus]

On Sat, 2006-03-18 at 20:10 +0100, Pascal Obry wrote:
> Ludovic Brenta a écrit :
> 
> > I see that I can change the default by patching
> > src/gcc/ada/Make-lang.in, which generates build/gcc/ada/sdefault.adb.
> > I think I'll do that, thus making the symlinks unnecessary, and
> > allowing GNAT to find all libraries' project files automatically.
> > 
> > Objections?
> 
> This is some more maintenance work... but you are doing all the work ;)
> so I have no objection.

Given that the GCC directory structure appears to be open to continuing
improvements, it might actually be advantageous to know where the heck
I can find a-chahan.ads when IDE navigation doesn't work.  :-)

I like this path abstraction.


-- Georg 

Re: Debian Policy for Ada, Second Edition

[Tapio Kelloniemi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]

Pascal Obry <pascal@obry.net> wrote:
>Ludovic Brenta a écrit :
>
>> I am not aware of a GNAT default.  What is the default? And why does
>> it not follow the GNAE?
>
>The scheme is something like:
>
>/opt/GNAT/<ver>
>  /bin                 <- binaries there
>  /lib/gnat/           <- project files there (GNAT looks there)
>  /lib/gnat/<project>  <- if needed sub-project files
>  /lib/<project>       <- .o .ali .a .so for <project>
>  /lib                 <- sym links to .a and .so above
>  /include/<project>   <- .ads/.adb for <project>

GNAT people seemingly haven't read FHS. This is what it says about the
include directory:
"This  is  where all of the system's general-use include files for the C
programming language should be placed."

Non-C languages generally use lib, like Python and Ruby. Even GNAT
installs its library's .adb and .ads files to lib/gcc/*/*/adainclude even 
though libstdc++ headers go to /usr/include/c++. I'm not saying that GNAT 
people made a wrong decision when they choose include, but at least they 
should be consistent.

I would like to raise the question publicly: where Ada-folks would like to put 
their .adb and .ads files? Well, perhaps this is redundant, since most likely 
people will follow the path set up by GNAT.. I'm very glad that after all 
these years GNAT developers have recognised that there must be a general way 
to link against external libraries, whereas this feature has always been 
present for C and C++ (at least in the GNU system).

-- 
Tapio

Library file locations (was: Debian Policy for Ada, Second Edition)

[Björn Persson]

Tapio Kelloniemi wrote:
> Pascal Obry <pascal@obry.net> wrote:
> 
>>Ludovic Brenta a écrit :
>>
>>
>>>I am not aware of a GNAT default.  What is the default? And why does
>>>it not follow the GNAE?
>>
>>The scheme is something like:
>>
>>/opt/GNAT/<ver>
>> /bin                 <- binaries there
>> /lib/gnat/           <- project files there (GNAT looks there)
>> /lib/gnat/<project>  <- if needed sub-project files
>> /lib/<project>       <- .o .ali .a .so for <project>
>> /lib                 <- sym links to .a and .so above
>> /include/<project>   <- .ads/.adb for <project>
> 
> 
> GNAT people seemingly haven't read FHS. This is what it says about the
> include directory:
> "This  is  where all of the system's general-use include files for the C
> programming language should be placed."

It doesn't forbid putting non-C files there. FHS doesn't mention Ada, so 
the most logical thing to do is to treat .ads files like .h files.

> Non-C languages generally use lib, like Python and Ruby.

Python doesn't have a system with separate specifications and 
pre-compiled libraries. A Python module is contained in a single file, 
so the Python developers had to choose between include and lib. 
Apparently they chose lib. I would guess that the situation with Ruby is 
similar.

> I would like to raise the question publicly: where Ada-folks would like to put 
> their .adb and .ads files?

The scheme that Pascal posted looks good, although I'm not sure lib/gnat 
is the best choice for project files. It should of course be under /opt 
only when installed as a third-party package. When it's included in an 
OS distribution, /opt/GNAT/<ver> should be replaced with /usr.

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Library file locations (was: Debian Policy for Ada, Second Edition)

[Tapio Kelloniemi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2478 bytes --]

Bj�rn Persson <spam-away@nowhere.nil>
>Tapio Kelloniemi wrote:
>> Pascal Obry <pascal@obry.net> wrote:
>>
>>>Ludovic Brenta a écrit :
>>>
>>>
>>>>I am not aware of a GNAT default.  What is the default? And why does
>>>>it not follow the GNAE?
>>>
>>>The scheme is something like:
>>>
>>>/opt/GNAT/<ver>
>>> /bin                 <- binaries there
>>> /lib/gnat/           <- project files there (GNAT looks there)
>>> /lib/gnat/<project>  <- if needed sub-project files
>>> /lib/<project>       <- .o .ali .a .so for <project>
>>> /lib                 <- sym links to .a and .so above
>>> /include/<project>   <- .ads/.adb for <project>
>>
>>
>> GNAT people seemingly haven't read FHS. This is what it says about the
>> include directory:
>> "This  is  where all of the system's general-use include files for the C
>> programming language should be placed."
>
>It doesn't forbid putting non-C files there. FHS doesn't mention Ada, so
>the most logical thing to do is to treat .ads files like .h files.

Generic bodies also go there and at least Debian requires that all .adb files
must be installed to this directory. Also putting Ada files to 
include/<project> may result in having both .h and .ad? files in the same 
directory, which may not be very comfortable. However, share/<project> is not 
better, since the project may use share for something else and because .ad?
files may not be architecture independent data.

>> Non-C languages generally use lib, like Python and Ruby.
>
>Python doesn't have a system with separate specifications and
>pre-compiled libraries. A Python module is contained in a single file,
>so the Python developers had to choose between include and lib.

Python has precompiled modules, with .pyc extension and they are kept in the 
same directories as the original source code.

>Apparently they chose lib. I would guess that the situation with Ruby is
>similar.
>
>> I would like to raise the question publicly: where Ada-folks would like to put
>
>> their .adb and .ads files?
>
>The scheme that Pascal posted looks good, although I'm not sure lib/gnat
>is the best choice for project files. It should of course be under /opt
>only when installed as a third-party package. When it's included in an
>OS distribution, /opt/GNAT/<ver> should be replaced with /usr.

GNAT should look for project files in /usr/local as well, but I'm
afraid this will not be done. Perhaps the project file directory should be 
changed to share/gnat.

-- 
Tapio

Re: Library file locations (was: Debian Policy for Ada, Second Edition)

[Björn Persson]

Tapio Kelloniemi wrote:
> Bj�rn Persson <spam-away@nowhere.nil>
>>Tapio Kelloniemi wrote:
>>>GNAT people seemingly haven't read FHS. This is what it says about the
>>>include directory:
>>>"This  is  where all of the system's general-use include files for the C
>>>programming language should be placed."
>>
>>It doesn't forbid putting non-C files there. FHS doesn't mention Ada, so
>>the most logical thing to do is to treat .ads files like .h files.
> 
> Generic bodies also go there and at least Debian requires that all .adb files
> must be installed to this directory.

To the extent that Gnat needs a library's .adb files when compiling a 
program, they too have the same function as the .h files. If you install 
bodies even though they aren't needed, I don't know of a standard 
location for them, but it seems logical to put them together with the 
specifications, especially if you already have generic bodies there.

> Also putting Ada files to 
> include/<project> may result in having both .h and .ad? files in the same 
> directory, which may not be very comfortable.

If it's one library that's written in part in C and in part in Ada, why 
would it be uncomfortable to have them in the same directory? If you're 
thinking of two different libraries, they need to have different names 
and different subdirectories under include.

>>>Non-C languages generally use lib, like Python and Ruby.
>>
>>Python doesn't have a system with separate specifications and
>>pre-compiled libraries. A Python module is contained in a single file,
>>so the Python developers had to choose between include and lib.
> 
> Python has precompiled modules, with .pyc extension and they are kept in the 
> same directories as the original source code.

Yes, but they have the same function as the .py files, only they're a 
bit faster to load. To import a module you need *either* a .py file *or* 
a .pyc file *or* a .pyo file. At least that's what the Python manual says:
http://www.python.org/doc/2.2.3/tut/node8.html#SECTION008120000000000000000
Whichever kind you have you need them at run time, so they function much 
like .so files. Therefore it makes sense to have them in /usr/lib.

To use a pre-compiled library from Ada you need *both* a set of source 
files (.ads and maybe .adb) *and* a binary file (.a or .so). Only then 
is it reasonable to keep sources and binaries separate.

It *would* have made a lot of sense to keep C headers closer to the 
binaries, in /usr/lib or maybe /usr/lib/include, but it's too late to 
change that. For Ada to integrate well in the Unix environment I think 
it's best to keep library files in the same places as corresponding C 
library files.

> GNAT should look for project files in /usr/local as well, but I'm
> afraid this will not be done. Perhaps the project file directory should be 
> changed to share/gnat.

Is there a good reason not to have project files somewhere under include 
or lib? I think they should be in one of /usr[/local]/include, 
/usr[/local]/include/<project>, /usr[/local]/lib and 
/usr[/local]/lib/<project>. (Substitute /opt/GNAT/<ver> for /usr when 
Gnat is a third-party package.)

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Library file locations (was: Debian Policy for Ada, Second Edition)

[Pascal Obry]

Tapio Kelloniemi a �crit :

> GNAT should look for project files in /usr/local as well, but I'm
> afraid this will not be done. Perhaps the project file directory should be 
> changed to share/gnat.

As I said this is not ok for handling multiple compilers. Remember that
the libraries you build is dependent on the compiler version used to
built it and can't be shared with another compiler. That's why having a
root install directory per compiler version (/opt/gnat/<ver> or
whatever) if a good scheme.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Library file locations (was: Debian Policy for Ada, Second Edition)

[Björn Persson]

Pascal Obry wrote:
> Tapio Kelloniemi a �crit :
>>GNAT should look for project files in /usr/local as well, but I'm
>>afraid this will not be done. Perhaps the project file directory should be 
>>changed to share/gnat.
> 
> As I said this is not ok for handling multiple compilers. Remember that
> the libraries you build is dependent on the compiler version used to
> built it and can't be shared with another compiler. That's why having a
> root install directory per compiler version (/opt/gnat/<ver> or
> whatever) if a good scheme.

Libraries installed under /usr should of course be compiled with the 
system compiler � the one that comes with the operating system 
distribution and is invoked through /usr/bin/gnatmake. If you install 
additional versions of Gnat, /opt/gnat/<ver> seems like a good place to 
put them and libraries for them.

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Library file locations (was: Debian Policy for Ada, Second Edition)

[Tapio Kelloniemi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

Pascal Obry <pascal@obry.net> wrote:
>Tapio Kelloniemi a �crit :
>
>> GNAT should look for project files in /usr/local as well, but I'm
>> afraid this will not be done. Perhaps the project file directory should be
>> changed to share/gnat.
>
>As I said this is not ok for handling multiple compilers. Remember that
>the libraries you build is dependent on the compiler version used to
>built it and can't be shared with another compiler.

This is not true. It is no more than a week when I upgraded GCC 4.0.2
to 4.1.0 on my Linux Ffrom Scratch system and I was able to upgrade glibc
with the new GCC without breaking anything. If all GCC's on the system target
the same architecture, one can compile libraries with one and applications
with another, if the compilers' ABI is the same.

> That's why having a root install directory per compiler version
> (/opt/gnat/<ver> or whatever) if a good scheme.

Yes it is, unless we are talking about the system Ada compiler. And back to my 
original idea of searching for project files in /usr/local/. You said that 
this can't be done, because multiple compilers must be supported. However GCC 
searches for header files in /usr/include and /usr/local/include even when it 
is installed under /opt. If some other behaviour is desired, GCC specs must be 
modified. So either GNAT should also use the same specs machanism as the rest 
of GCC (we agree that GNAT should behave the same way as other compilers in 
GCC?) or it should:
- Search from /usr/local if and only if it will be installed to /usr.
and/or
- Provide an easy way for system administrators to change the project search 
  path. Perhaps a file like ada_project_path could be added to lib/gcc/*/* 
  where ada_object_path and ada_source_path files may also reside.

-- 
Tapio

Re: Library file locations (was: Debian Policy for Ada, Second Edition)

[Ludovic Brenta]

Tapio Kelloniemi <spam18@thack.org> writes:
[...] 
> However GCC searches for header files in /usr/include and
> /usr/local/include even when it is installed under /opt. If some
> other behaviour is desired, GCC specs must be modified. So either
> GNAT should also use the same specs machanism as the rest of GCC (we
> agree that GNAT should behave the same way as other compilers in
> GCC?) or it should:
> 
> - Search from /usr/local if and only if it will be installed to /usr.
> and/or
> - Provide an easy way for system administrators to change the project search 
>   path. Perhaps a file like ada_project_path could be added to lib/gcc/*/* 
>   where ada_object_path and ada_source_path files may also reside.

The Debian Policy for Ada says that each library must provide a
project file called /usr/share/ada/adainclude/LIBRARY.gpr.

I intend to have the system Ada compiler look for project files in
that directory by default.

Each user can, in addition, have project files anywhere they please,
and define ADA_PROJECT_PATH so GNAT will find them automatically.
They can also "with" any project file by means of its fully-qualified
file name if they so wish.

In particular, /usr/local is, by definition, for use by the system
administrator, and therefore falls outside the scope of any policy
defined by the operating system.  If you want GNAT to look in some
particular subdirectory of /usr/local, then use ADA_PROJECT_PATH or
"with" the fully qualified file name of your project files.

So, what exactly is the problem?

-- 
Ludovic Brenta.

Re: Library file locations (was: Debian Policy for Ada, Second Edition)

[Tapio Kelloniemi]

Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:
>Tapio Kelloniemi <spam18@thack.org> writes:
>[...]
>> However GCC searches for header files in /usr/include and
>> /usr/local/include even when it is installed under /opt. If some
>> other behaviour is desired, GCC specs must be modified. So either
>> GNAT should also use the same specs machanism as the rest of GCC (we
>> agree that GNAT should behave the same way as other compilers in
>> GCC?) or it should:
>>
>> - Search from /usr/local if and only if it will be installed to /usr.
>> and/or
>> - Provide an easy way for system administrators to change the project search
>>   path. Perhaps a file like ada_project_path could be added to lib/gcc/*/*
>>   where ada_object_path and ada_source_path files may also reside.
>
>In particular, /usr/local is, by definition, for use by the system
>administrator, and therefore falls outside the scope of any policy
>defined by the operating system.

Why GCC then looks for headers in /usr/local/include? Because many packages
are installed in /usr/local by sysadmins and because /usr/local/include
is in GCC's default search path, other packages can link against 
packages installed by admin without using absolute paths. Has anyone ever
seen C code like:
#include "/usr/local/include/readline/readline.h"

What comes to setting ADA_PROJECT_PATH, I think it is just setting
one more redundant environment variable. Editing a text file is much more
elegant solution.

> If you want GNAT to look in some
>particular subdirectory of /usr/local, then use ADA_PROJECT_PATH or
>"with" the fully qualified file name of your project files.

Let us think that I'm to publish my application A in source format on my
web site. The package is built with a command like:
gnatmake -PA

If my project file contains something like:
with "/usr/share/ada/adainclude/florist.gpr";
with "/...";
with "/...";

Suddenly I'll get a lot of complaints that compiling my application is very
frustrating because users must hassle with the absolute path definitions
in my project file.

>So, what exactly is the problem?

Easy usage of libraries, no matter whether they are installed by a sysadmin
or a distro.

--
Tapio

Re: Library file locations (was: Debian Policy for Ada, Second Edition)

[Ludovic Brenta]

Tapio Kelloniemi <spam18@thack.org> writes:
>>In particular, /usr/local is, by definition, for use by the system
>>administrator, and therefore falls outside the scope of any policy
>>defined by the operating system.
>
> Why GCC then looks for headers in /usr/local/include? Because many packages
> are installed in /usr/local by sysadmins and because /usr/local/include
> is in GCC's default search path, other packages can link against 
> packages installed by admin without using absolute paths. Has anyone ever
> seen C code like:
> #include "/usr/local/include/readline/readline.h"

No but I often see:

gcc -c -I/usr/local/include foo.c

> What comes to setting ADA_PROJECT_PATH, I think it is just setting
> one more redundant environment variable. Editing a text file is much
> more elegant solution.

But you would normally set ADA_PROJECT_PATH from within a Makefile, so
your objection is weak.

>> If you want GNAT to look in some
>>particular subdirectory of /usr/local, then use ADA_PROJECT_PATH or
>>"with" the fully qualified file name of your project files.
>
> Let us think that I'm to publish my application A in source format on my
> web site. The package is built with a command like:
> gnatmake -PA
>
> If my project file contains something like:
> with "/usr/share/ada/adainclude/florist.gpr";
> with "/...";
> with "/...";
>
> Suddenly I'll get a lot of complaints that compiling my application is very
> frustrating because users must hassle with the absolute path definitions
> in my project file.

As I said, gnat-4.1 will look in /usr/share/ada/adainclude by default,
so you will not need absolute paths.  So your objection is addressed.

Secondly, even if gnat didn't look in that directory by default,
nobody could blame you for following the GNAE standard, could they?

>>So, what exactly is the problem?
>
> Easy usage of libraries, no matter whether they are installed by a
> sysadmin or a distro.

And the Debian Policy for Ada addresses just that problem.  I meant,
what is the *remaining* problem after you've read the Debian Policy
for Ada?

-- 
Ludovic Brenta.

Re: Library file locations (was: Debian Policy for Ada, Second Edition)

[Tapio Kelloniemi]

Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:
>Tapio Kelloniemi <spam18@thack.org> writes:
>>>In particular, /usr/local is, by definition, for use by the system
>>>administrator, and therefore falls outside the scope of any policy
>>>defined by the operating system.
>>
>> Why GCC then looks for headers in /usr/local/include? Because many packages
>> are installed in /usr/local by sysadmins and because /usr/local/include
>> is in GCC's default search path, other packages can link against
>> packages installed by admin without using absolute paths. Has anyone ever
>> seen C code like:
>> #include "/usr/local/include/readline/readline.h"
>
>No but I often see:
>
>gcc -c -I/usr/local/include foo.c

This -I is redundant and must be treated as somebody else's problem.

>> What comes to setting ADA_PROJECT_PATH, I think it is just setting
>> one more redundant environment variable. Editing a text file is much
>> more elegant solution.
>
>But you would normally set ADA_PROJECT_PATH from within a Makefile, so
>your objection is weak.

I don't think that /usr/local is very non-standard location for installing
software. Actually if I daily used a system where there is a package manager 
provided by the distro, I would not install programs compiled by myself in the 
/usr hierarchy. You know better than I what happens if a sysadmin installs a 
package in /usr which overwrites a file already installed by the distro. 
Therefore it is good practice to install under /usr/local to prevent messing 
up the system's package management, and for other reasons as well.
This is why /usr/local should be supported automatically or at least easily.
What comes to setting ADA_PROJECT_PATH in a Makefile:
Imagine that I have installed some Ada library under /usr/local (the distro 
provides a precompiled binary, but I want to enable a feature X required by 
package A). Then I compile A. If the library and the package A were written in 
C, I would do the following to compile A:
./configure && make && make install

As they are written in Ada, I do:
./configure --with-additional-ada-project-path=/usr/local/share/ada/adainclude

And what if the configure script does not support the above mentioned option?
I would have to edit Makefiles, possibly run automake, etc. If the 
compilation process happens to be automated, I must write some nasty sed 
scripts to do the job.

-- 
Tapio

Re: Library file locations

[Ludovic Brenta]

Tapio Kelloniemi <spam18@thack.org> writes:
> I don't think that /usr/local is very non-standard location for installing
> software. Actually if I daily used a system where there is a package manager 
> provided by the distro, I would not install programs compiled by myself in the 
> /usr hierarchy. You know better than I what happens if a sysadmin installs a 
> package in /usr which overwrites a file already installed by the distro. 
> Therefore it is good practice to install under /usr/local to prevent messing 
> up the system's package management, and for other reasons as well.
> This is why /usr/local should be supported automatically or at least easily.
> What comes to setting ADA_PROJECT_PATH in a Makefile:
> Imagine that I have installed some Ada library under /usr/local (the distro 
> provides a precompiled binary, but I want to enable a feature X required by 
> package A). Then I compile A. If the library and the package A were written in 
> C, I would do the following to compile A:
> ./configure && make && make install
>
> As they are written in Ada, I do:
> ./configure --with-additional-ada-project-path=/usr/local/share/ada/adainclude
>
> And what if the configure script does not support the above
> mentioned option?  I would have to edit Makefiles, possibly run
> automake, etc. If the compilation process happens to be automated, I
> must write some nasty sed scripts to do the job.

Ada programs do not normally require configure scripts.  I tend to
think of configure scripts as symptoms of bad engineering.  Automake?
Why use automake?  KISS!

ADA_PROJECT_PATH=/usr/local/share/ada/adainclude make

is sufficient and addresses your concern that "/usr/local should be
supported automatically or at least easily" - for easy it is, indeed.
And yes, if it's under /usr/local, then it's outside of the distro's
responsibility - "someone else's problem" is indeed "the
administrator's problem".

A second easy way to support /usr/local is:

echo "ADA_PROJECT_PATH=/usr/local/share/ada/adainclude" >> /etc/environment

which is, of course, an implementation of a local (system-wide) policy
decided by the administrator and not the distro.

-- 
Ludovic Brenta.

Re: Library file locations (was: Debian Policy for Ada, Second Edition)

[Georg Bauhaus]

Tapio Kelloniemi wrote:


>  /usr/local should be supported automatically or at least easily.
> What comes to setting ADA_PROJECT_PATH in a Makefile:

As the name 'local' says (to me, at least), what is in /usr/local
should be treated as local. Hence a global compiler should not at
all have knowledge of, or be interest in, what is in /usr/local.

> Imagine that I have installed some Ada library under /usr/local (the distro 
> provides a precompiled binary, but I want to enable a feature X required by 
> package A). Then I compile A. If the library and the package A were written in 
> C, I would do the following to compile A:
> ./configure && make && make install
> 
> As they are written in Ada, I do:
> ./configure --with-additional-ada-project-path=/usr/local/share/ada/adainclude
> 
> And what if the configure script does not support the above mentioned option?

I do hope that use of configure etc is rare with Ada. Reason 1:
Ada itself has good configuration facilities. Reason 2: Make is pretty
good in steering them. Ada compilation systems tend to have project
compilation management programs. Reason 4: Unlike Ada, auto* is horribly
non-portable across OS toolsets, and has been shown to contribute to the
problem it is supposed to solve.


Georg 

Re: Library file locations (was: Debian Policy for Ada, Second Edition)

[Pascal Obry]

Tapio Kelloniemi a �crit :

> This is not true. It is no more than a week when I upgraded GCC 4.0.2
> to 4.1.0 on my Linux Ffrom Scratch system and I was able to upgrade glibc

We are speaking of GNAT Ada libraries there! What is said is true in
this context.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Library file locations (was: Debian Policy for Ada, Second Edition)

[Tapio Kelloniemi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

Pascal Obry <pascal@obry.net> wrote:
>Tapio Kelloniemi a �crit :
>
>> This is not true. It is no more than a week when I upgraded GCC 4.0.2
>> to 4.1.0 on my Linux Ffrom Scratch system and I was able to upgrade glibc
>
>We are speaking of GNAT Ada libraries there! What is said is true in
>this context.

Oops.. Seems that you are right. I had a source tre containing objects 
generated with GCC-4.0.2. I touched one file and compiled it with GCC-4.1.0 
and it recompiled everything. Is there some reason for this or does GNAT's ABI 
change in every release? Will I be able to link agains libraries compiled with 
4.1.0 when I upgrade to 4.1.1? This seems like a major problem...

-- 
Tapio