[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: