Hello,
Adacore released 2015th version of its packages too late for self-contained change submissiom however xmlada, gprbuild, aws and aunit have been updated to version '2015'. Gnatcoll is coming soon and then florist (It requires to patch C code a lot and I don't like it)
Since this release gprbuild can build arm packages (gprbuild-%{version}-arm_compiler.patch). Since this release gprbuild don't use gnatmake by default to build itself (and this introduce new problem during initial build because xmlada requires gprbuild abd gprbuild requires xmlada and gprbuild) Most of the packages use gprinstall instead of cp/install in install target so I didn't use "directories.gpr".
-- Pavel
Pavel Zhukov wrote:
Adacore released 2015th version of its packages too late for self-contained change submissiom however xmlada, gprbuild, aws and aunit have been updated to version '2015'. Gnatcoll is coming soon and then florist (It requires to patch C code a lot and I don't like it)
And in a week or two I'll have time to look into upgrading GTKada.
Matthew Miller mentioned on the devel list that one can file a release notes request without going through the Change process. It's probably not too late for that yet. https://lists.fedoraproject.org/pipermail/devel/2015-June/211747.html
Since this release gprbuild don't use gnatmake by default to build itself (and this introduce new problem during initial build because xmlada requires gprbuild abd gprbuild requires xmlada and gprbuild)
These cyclical dependencies also look like they could cause big problems every time GCC gets upgraded and the soname of libgnat changes. GPRbuild will stop working when the old libgnat disappears from the buildroot, and then we can't build a new GPRbuild because that requires a working GPRbuild. Do you have a plan to handle that? Static linking?
Most of the packages use gprinstall instead of cp/install in install target so I didn't use "directories.gpr".
I looked at the Aunit package to see an example. It's not quite as bad as I feared. In the manual it looked like GPRinstall had no support for installing to a staging directory, so I was afraid that it would embed the pathname of the staging directory in the usage project files it generates. I see now that it uses relative pathnames, so that's not an issue.
You have lost multilib compatibility though. 32- and 64-bit -devel packages will conflict with each other. I suppose the only ways to fix that while using GPRinstall are to fix up the generated project files at the end of the %install section, or to discard the generated project files and write our own. Patching a project file in %install doesn't seem significantly more difficult than doing it in %prep, but it may be that Sed would be a better choice than Patch for post-processing generated files.
Björn