default directories in installed library projects
This message answers
https://lists.debian.org/debian-ada/2013/09/msg00005.html
> users have to use setarch instead of passing an option such as -m32
Gnat will not be able to cross-compile before long. Why not hardcode
the hardware platform into directories.gpr? Could you give an example
where gnat needs to receive a target architecture at compile time?
> Perhaps Debian has something similar that is available when packages
> are built?
On Debian systems, dpkg-architecture is called to consult arch name
variants (here, DEB_[HOST|TARGET]_MULTIARCH: the clarified GNU system
type of the machine, used for filesystem paths). But Ada package are
not cross-compiled.
> how do you feel about "operating_system_directories", or
> "os_directories" for short? Or is "distribution_directories" better?
I prefer "distribution_directories" or even
"distribution_directory_layout". Long names seem ok for internal
names that normal users will never have to type or remember, but risk
to pollute the namespace.
> I fail to imagine why anyone would write architecture-dependent
> package specifications in Ada. It shouldn't be hard to encapsulate
> the architecture-dependent bits in a package body.
Architecture-dependent package specifications seem a necessary pain
for C bindings like gmp, ncurses, gtk, qt.
For Bindir and Libexecdir: could you please provide an example
scenario of use of these variables? If an user ever installs his
library system-wide, he will probably want to avoid locations used by
the distributions, and select something like /usr/local or /opt
instead. Our project only intends to help him during compilation.
Concerning the name of these variables, they will
* be written once by a program into distribution_directory_layout.gpr
during creation of the gnat-x.y package,
* be read by only two programs, gnatmake or gprbuild, when the project
is withed by a reverse dependency,
* live inside the distribution_directory_layout.gpr name space.
So risks of confusion are quite limited. However, for the same reason,
I do not mind adopting your names :-).
> This example shows a shared library that depends on a second library but
> isn't linked to that library. Instead the first library requires that
> programs and libraries that use it must link to the second library. I
> suppose this is normal for static libraries, but a shared library should
> normally be linked to the libraries it depends on.
On Debian at least, if libbar depends on libfoo, -lfoo must be given
both when linking libbar and later when linking an executable with
libbar. I have read what you say in some documentations, but the link
step actually failed every time I tried.
Libexecdir: you write
The top-level directory for programs that are intended to be run by
other programs rather than by users.
I prefer:
The parent of libraries' separate library-specific directories for
programs that...
because the Debian policy recommends it (A subdirectory named after
the package ensures that the path depends on the SOversion).
So, here is a proposition for the Debian Ada policy.
* gnatmake and gprbuild are modified to look for projects into
/usr/lib/DEB_HOST_MULTIARCH/ada/adainclude/
* gnat-x.y delivers a new
/usr/lib/DEB_HOST_MULTIARCH/ada/adainclude/distribution_directory_layout.gpr
project with the following contents:
abstract project Distribution_Directory_Layout is
Hardware_Platform := "DEB_HOST_MULTIARCH of GNAT-x.y";
Bindir := "/usr/bin/";
Includedir := "/usr/share/ada/adainclude/";
Libdir := "/usr/lib/" & Hardware_Platform & "/";
Libexecdir := "/usr/lib/" & Hardware_Platform & "/libexec/";
Archincludedir := "/usr/lib/" & Hardware_Platform & "/ada/adainclude/";
Alidir := "/usr/lib/" & Hardware_Platform & "/ada/adalib/";
end Distribution_Directory_Layout;
* libfooALI-dev writes its project as below, so that
- it depends less on the distribution,
- it will usually be arch-independent (but if not can safely
go to /usr/lib/DEB_HOST_MULTIARCH/ada/adalib/LIBRARY.gpr).
- it allows to move arch-dependent sources in an arch-dependent path,
- the -dev package can be marked as multiarch.
with Distribution_Directory_Layout;
library project LIBRARY is
package DDL renames Distribution_Directory_Layout;
for Library_Name use project'Name;
for Library_Kind use "dynamic";
for Library_Dir use DDL.Libdir;
for Source_Dirs use (DDL.Includedir & project'Name,
DDL.Archincludedir & project'Name); -- if needed
for Library_ALI_Dir use DDL.Alidir & project'Name;
for Externally_Built use "True";
package Linker is -- If needed:
for Linker_Options use ("-lANY", "-lDEPENDENCY");
end Linker;
package Naming is -- If needed:
for Implementation ("UNIT") use "PATH";
end Naming;
end LIBRARY;
I also suggest to use this occasion for two cosmetic changes.
* drop the duplicates "ada" in our default paths (shorter paths)
* separate the projects from the sources (better autocompletion).
Suggestion:
The project goes to
/usr/share/ada/gpr/LIBRARY.gpr
or, if it ever depends on the archictecture:
/usr/lib/DEB_HOST_MULTIARCH/ada/gpr/LIBRARY.gpr
ALI files go to
/usr/lib/DEB_HOST_MULTIARCH/ada/ali/LIBRARY/*.ali
Most sources go to
/usr/share/ada/src/LIBRARY/*.[adb,ads,c,h]
but the few depending on the architecture go to
/usr/lib/DEB_HOST_MULTIARCH/ada/src/LIBRARY/*.ad[bs]
Reply to: