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@xxxxxxxxxxxxxxxxxxxx> 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review