[gtkada] improvements to the GtkAda build system

[Björn Persson]

Arnaud Charlet wrote:
> > On the other hand the relative paths don't work in a 64-bit Fedora where
> > the libraries are in /usr/lib64 but the project files have to be in
> > /usr/lib/gnat.
> 
> They don't "have to be", you could change that (either via a system wide
> env variable, or by modifying gnat tools).

Yes, and when I can find some time I'll investigate how we can move the project 
files in Fedora to /usr/share/gpr, because they really don't belong under 
/usr/lib.

It may seem like we could just set GPR_PROJECT_PATH to "/usr/lib64/gnat", but 
that doesn't work in a multilib system. If we would treat project files as 
architecture-specific, putting project files for 64-bit libraries in 
/usr/lib64/gnat and those for 32-bit libraries in /usr/lib/gnat, then Gnat 
itself would also have to treat them as architecture-specific. It would either 
have to use separate project paths for different target architectures, or else 
an architecture would have to be encoded in each project file so that Gnat 
could skip the ones intended for another architecture.

Gnat does neither of those things. It has a single project path and uses the 
first project file with the right name that it finds. Since Gnat treats project 
files as architecture-independent, we packagers need to package them in such a 
way that they really are architecture-independent. In Fedora we do that by 
patching the project files to import a project named Directories, where the 
variable Libdir is defined based on an environment variable, and then deriving 
Library_Dir and Library_ALI_Dir from Directories.Libdir. (We also derive 
Source_Dirs from Directories.Includedir, but that one is constant.) That way 
the very same project file will point to libraries in /usr/lib or /usr/lib64 
depending on what the current architecture is. Thus the project files are 
architecture-independent, and therefore they belong under /usr/share.

> > I suppose I could make an option to allow choosing between absolute and
> > relative paths. Is there a chance that you would accept that?
> 
> Not really, that would add a level of complexity that would hurt
> maintenance I suspect.

It doesn't really matter to me actually. As I described above I'll replace the 
paths with Directories.Includedir and Directories.Libdir anyway. I merely 
tried to do the right thing by using Autoconf macros consistently.

What about the rest of the directory variables patch? Are those changes 
acceptable if I remove the changes to the project files?

Björn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : /pipermail/gtkada/attachments/20110330/293bfc80/attachment.pgp