arch-dependent files in -dev packages
With the gnat-4.8 transition, we may consider changing the policy for
-dev packages to avoid architecture-dependent contents in /usr/share/.
You may want to (re-)read Björn's idea about projects [π], the
discussion about arch-dependent sources ([√2] and same thread next
month [i]), or the wiki about multiarch in Debian [-1].
[π] https://lists.debian.org/debian-ada/2011/12/msg00000.html
[√2] https://lists.debian.org/debian-ada/2012/04/msg00040.html
[i] https://lists.debian.org/debian-ada/2012/05/msg00001.html
[-1] https://wiki.debian.org/Multiarch/Implementation
The gnat package would install a configuration project in
"/usr/share/ada/adainclude/", inheriting the target architecture at
each build, and implementing the local directory hierarchy policy.
I have no idea of the best way to inherit TARGET_ARCH, though. Ideas?
In order to share library projects with at least Fedora, we should
agree on some details.
The project name must avoid collision with any user-defined project
name. The "system" and "variable" words do not carry much information
in that context. Why not "installed_library_directories.gpr"?
If I understand well, this project is only useful for compilation. If
so, bindir and libexecdir, intended as installation destinations,
should not belong to it. Installation belongs to dpkg/rpm, not to gnat
tools.
Defining an "Archincludedir" variable would encourage libraries to use
the same layout, at least inside a distribution.
If Debian aims at minimal changes, "/usr/lib/ARCH/ada/adainclude/NAME"
seems a natural choice.
For convenience of programmers and code browsing tools, a symbolic
link could be provided from Archincludedir/SRC to Includedir/SRC for
every arch-indep source. Gnat would not be confused because when it
finds identical file names in two directories, it only considers the
first one. I mention the idea for the record, but I dislike link
forests.
Concrete suggestion:
----------------------------------------------------------------------
-- Debian version of /usr/share/ada/adainclude/installed_lib_dirs.gpr
abstract project Installed_Lib_Dirs is
for Source_Files use ();
Deb_Host_Multiarch := external ("TARGET_ARCH");
Library_Dir := "/usr/lib/" & Deb_Host_Multiarch;
Library_ALI_Dir := "/usr/lib/" & Deb_Host_Multiarch & "/ada/adalib";
Arch_Dep_Source_Dir := "/usr/lib/" & Deb_Host_Multiarch & "/ada/adainclude";
Arch_Indep_Source_Dir := "/usr/share/ada/adainclude";
end Installed_Lib_Dirs;
----------------------------------------------------------------------
-- Common contents for /usr/share/ada/adainclude/NAME.gpr
-- This project file is designed to help build applications that use NAME.
-- Here is an example of how to use this project file:
-- with "NAME";
-- project Example is
-- for Main use ("example.adb");
-- end Example;
with "installed_lib_dirs";
with "dep_providing_an_importable_project";
library project NAME is
for Library_Name use project'Name;
for Library_Kind use "dynamic";
for Externally_Built use "true";
for Source_Dirs use
(Installed_Lib_Dirs.Arch_Indep_Source_Dir & "/" & project'Name,
Installed_Lib_Dirs.Arch_Dep_Source_Dir & "/" & project'Name);
for Library_ALI_Dir use Installed_Lib_Dirs.Library_ALI_Dir & "/" & project'Name;
for Library_Dir use Installed_Lib_Dirs.Library_Dir;
package Linker is
for Linker_Options use ("-ldep_providing_no_importable_project");
end Linker;
end NAME;
----------------------------------------------------------------------
A connected problem: in worst cases, the list of dependencies
providing no importable projects may depend on the target
architecture. As long as #717014 exists, this may happen even for Ada
sources.
An arch-indep work-around for this exact bug is to append
"-Wl,--as-needed -lbar -Wl,--no-as-needed" to linker options (or -lbar
if --as-needed is already the default). This embeds -lbar when and
only when needed on the target architecture, but not efficiently.
I mention the problem here because any better idea is welcome, and
because the work-around should be documented in policy in the
paragraph enforcing arch-indep gpr files.
--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it. – Brian Kernighan
Reply to: