3:05 p.m.
Pavel Zhukov wrote:
Bjorn, I can understand your point here but comfignat is just one
more project It can invoked (using fedora-gnat-project-common) some
macroses but I'd not like to change Guidelines. In that case we'll
introduce %{awsmake} %{awsmake_install}, %{matreshkamake}
%{mynicepackagemake} macroses soon (and yes. matreshka uses its own
nice configuration syste). Gnatmake and gprbuild is the standard and
should be documented comfignat is not (yet).
I'm not sure I understand what you're trying to say here. Do you mean
that it's okay to use Comfignat_make but it should be undocumented?
That's actually forbidden by the current policy which says that either
Gnatmake_optflags or GPRbuild_optflags must be used. Or do you mean that
you want Comfignat_make to remain forbidden?
Yes, Matreshka has its own build system and AWS has its own. Every Ada
package has its own custom build system (except for those that have no
build system at all and leave it to the users to compile the source
code as they see fit). Each one has its own names for options variables
and directory variables, and most are inflexible and have to be hacked
to support Fedora's packaging standards. This slows us packagers down
and leads to packaging bugs – like the missing optflags in Matreshka
that you just fixed. I've had to wrestle a lot with GTKada's build
system even though it uses Autoconf. I'm trying to improve the situation
by establishing some conventions and a build system foundation that
helps developers follow the conventions.
It's true that Comfignat isn't popular yet. It's only been four months
since I released the first version. So how many Comfignat-using
packages do you think there should be before it's worthy of a macro?
> templates_parser.spec does
> «LD_LIBRARY_PATH="`pwd`/.build/native/release/relocatable/lib/"
> make doc». In that case the spec file must know the internal
> structure of the build directory just to work around a problem that
> Gnatmake_optflags
The maintainer must know the structure of the build directory anyway.
Information hiding is important to keep software maintainable. The code
in one module should only use the APIs of other modules and not depend
on their internals, even though the programmer often knows the
internals of all the modules.
Now, makefiles don't usually have very well-defined APIs, but we can try
not to make it worse.
In you case maintainer must use chrpath to remove Rpath in
$install section and this is last resort[1].
The example programs in Templates Parser's manual are never installed.
They are compiled and run during the build, and their output is
included in the manual along with the input and the source code, but
the compiled programs exist only in the build directory. There's no
need to use chrpath on them. It's the same with test suites. It's not a
problem if they have runpaths because they aren't included in the built
packages.
Björn Persson