Pavel Zhukov wrote: Comfignat consists of a generic makefile foundation and a template of an abstract GNAT project that will be bundled with the source packages that use it. The files need to be in the source tree so that Make will find them, so there's no point in packaging Comfignat. Comfignat is here by the way, for anyone who is interested: https://www.rombobjörn.se/Comfignat/ I've been helping Tero Koskinen to remake Ahven's build system around Comfignat, and he says he'll make a new release soon. I want to package Ahven to be able to run the test suites of Anet, Alog and the Trusted Key Manager. Anet is already packaged but without a %check section. I also use Comfignat in some projects of my own that will hopefully be ready to be packaged some day. You can do it that way if it works for you. The GNAT_add_rpath mechanism is there if you need it. Setting LD_LIBRARY_PATH to "%{buildroot}/%{_libdir}" is reasonably clean. 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 has introduced, which is a bit messy. GNAT_add_rpath would be a cleaner solution there. Björn Persson

Pavel Zhukov wrote: 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? 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. 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