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