[Bug 509158] Review Request: fedora-gnat-project-common – files shared by Ada libraries

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=509158





--- Comment #8 from Björn Persson <bjorn at xn--rombobjrn-67a.se>  2009-07-03 18:28:48 EDT ---
(In reply to comment #7)
> Hmm, has this package been brought to attention of Fedora's GCC maintainers or
> upstream GCC?

Well, it blocks review request 509159, which depends on bug 507247, which is a
bug in GCC that I hope at least Jakub Jelinek is aware of. Other than that I
haven't contacted the GCC maintainers yet.

It's quite possible that some or all of this package ought to be included in
the gcc-gnat package eventually, but I felt that it would be more flexible to
make a separate package initially. If I find, as I continue packaging Ada
software, that I need another RPM macro or project file variable, then I can
add it to this package quickly without requiring an update to GCC. When my
approach has stabilized and proven itself functional, as I hope it will, then
it may be time to merge it into the gcc-gnat package, or even upstream GCC.

> * gnat has been multilib'ed in gcc.

I want to use GNAT project files to make Ada libraries easy to use. The project
files have to reference architecture-specific library files in either /usr/lib
or /usr/lib64. That means either the project files have to be
architecture-specific, or else a single project file must be made to change its
behaviour depending on the architecture. Architecture-specific project files
would have to be placed in architecture-specific directories, so that both
versions could be installed simultaneously in a multilib environment. Then GNAT
would have to look for project files in the one or the other directory, not
depending on which version of GNAT is installed, but depending on which
architecture it's compiling for at the moment. As far as I can see, GNAT has no
support for that. Therefore I chose the other approach, to make the project
files adapt to the architecture. Rather than duplicating the code to do that in
each project file, they should import common.gpr.

> * the profile.d scripts pollute the envionment.

They do, and I'm not happy about it. It's not even a complete solution as (I
think) they're effective only in interactive shells. Nonetheless it's the best
solution I could find. I can't invoke uname from common.gpr because GNAT
project files have no shell-out feature. I thought I had found the solution
when I saw the variable HOSTTYPE, but apparently Bash doesn't export that to
child processes, and it's not affected by setarch. At least these scripts will
pollute the environment only for programmers who install -devel packages that
depend on this package.

> Finally, this spec looks really bewildering to me
> - The %global _GNAT_project_dir ... line
> This can be done very much efficient during a %build

I agree that it's ugly but I figured that the SPOT rule was more important.
This directory is already defined twice, in macros.gnat in this package, and
somewhere in the GCC source. I didn't want to add a third location by
hard-coding it in the spec file.

How do you mean it should be done in %build? By defining the directory in the
spec file and writing it to macros.gnat during %build? I considered that but
then the "upstream project" wouldn't contain the complete source code, which I
found a bit weird. I can do it that way however, if it's deemed preferable.

> - We do not support translations in *.specs  

Then why do I find this SHOULD item on
https://fedoraproject.org/wiki/Packaging/ReviewGuidelines?
"The description and summary sections in the package spec file should contain
translations for supported Non-English languages, if available."

How else do you think translations should be done?

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.