<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Werner,</div><div><br></div><div>First of all I must say that I fully agree with you that pkg-config is not the idle implementation, yes, I can think of many improvements and suggestions. However, the question... is it good enough.<br></div><div><br></div><div>The fact that you plan to publish pkg-config metadata as "second class citizen", suggests that we already understand that we support the lowest common denominator, which is pkg-config capabilities. At the next ABI break (which is as you pointed one of the missing features of pkg-config. Well, apart of the obvious provide a new metadata name which you do not like) you will have to consider both script based and pkg-config implications on your consumers.<br></div><div><br></div><div>I am still waiting you to address the actual patch... Provided gnupg libraries already publish pkg-config metadata, this trivial patch provides the option to select either mode, while keeping current approach as the default. Everybody wins... you keep upstream build pkg-config free whenever possible, while providing downstream and users to use pkg-config if there is a benefit of doing so.</div><div><br></div><div>For your question about the current config scripts and cross compile, I already provided some missing bits... Here they are again:<br></div><div><br></div><div>1. Executables and/or scripts within SYSROOT is to be used only by target machine, when building nothing should be executed out of SYSROOT. [[pkg-config solves this by reading metadata out of the SYSROOT]]<br></div><div><br></div><div>2. The tools should be installed as ${HOST}-${TOOL}, so that multiple modes can be supported. This applies also for non-cross compile, such as multilib. [[pkg-config solves this by installing the metadata under the libdir]]</div><div><br></div><div>3. Tools should be SYSROOT aware, and output paths based on SYSROOT. [pkg-config solves this by adding PKG_CONFIG_SYSROOT_DIR as prefix to absolute paths]]<br></div><div><br></div><div>4. In autoconf you should use AC_*_TOOL instead of AC_*_PROG to locate these configuration scripts, this will search for a tool prefixed with ${HOST}-, it will find the right script per the target host, and it is the standard autoconf practice for build tools. [[pkg-config solves this by reading metadata from SYSROOT:libdir]]<br></div><div><br></div><div>
<div>5. The standard method would be to 
install ${HOST}-${TOOL} at SYSROOT/*/bin per (2) to serve the target 
system, while installing a ${HOST}-${TOOL} at build /*/bin with SYSROOT 
consideration, default where SYSROOT was when building the package. This
 will allow autoconf (4) to find it without any tweaks, per autoconf best practices.<br></div><div><br></div>

</div><div>5. Instead of (5), you can tweak the AC_*_TOOL (4) will search the SYSROOT/*/bin for the tools. However, you must still support the ${HOST}- prefix (2). This option still violate (1) the fact that nothing from SYSROOT should be executed during cross-compile, and should be avoided.<br></div><div><br></div><div>Supporting pkg-config as an option solves these issues without adding more logic into scripts/autoconf/automake/users with this simple patch. You can decide in future to solve this properly also using the config scripts.</div><div><br></div><div>Even if you decide to solve this in config scripts, and based on the fact that the config scripts already read pkg-config metadata... Probably the simplest option is to merge all scripts into a single script as the logic is the same, then provide a pkg-config compatible interface for this script, in other words, create a mini-pkg-config, so that autoconf might fallback to this script when pkg-config is not available.<br></div><div><br></div><div>Regardless of the discussion of how to improve the config scripts, can you please consider to add the pkg-config as an optional method?<br></div><div><br></div><div>Regards,</div><div>Alon<br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 17, 2018 at 12:30 PM Werner Koch <<a href="mailto:wk@gnupg.org" target="_blank">wk@gnupg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, 13 Oct 2018 00:07, <a href="mailto:alon.barlev@gmail.com" target="_blank">alon.barlev@gmail.com</a> said:<br>
<br>
> make was introduced to manage a set of simple rules to avoid re-build<br>
> when possible, then realized that for large project it is difficult to<br>
<br>
make was also devised in 1976 as a simple form of dependency tracker to<br>
make sure that changed source file won't go unnoticed.<br>
<br>
> autoconf was introduced to generate files from templates based on<br>
> logic as it was difficult to add functional logic into make files.<br>
<br>
That more describes imake.  autoconf impelements the GNU strategy to<br>
first test a system for features and the use only standard style macros<br>
to make use of system specific features.   This avoided the often deep<br>
nested ifdef chhains you still see in some software. <br>
<br>
> automake was introduced to provide a simple method to generate make<br>
> files that actually work with less error prune syntax, supporting<br>
<br>
Right.  And to make sure that the required targets are always availabale<br>
(e.g. make distcheck).<br>
<br>
> These concerns could have been address using metadata or scripts, at<br>
> first there was no standard for metadata, so these programs that<br>
<br>
This is why autoconf runs tests.  The meta data provided by libraries<br>
are actually not tests but hints on how they were configured.<br>
<br>
> selection to manage the metadata, having consistent behavior among<br>
> packages, not running anything from sysroot - all is important to<br>
<br>
Why should one not run something from sysroot?  POSIX shell scripts are<br>
well suited to be run on all platforms, be it on the build system or or<br>
final host (after installation or shared with an emulator).<br>
<br>
> The gnupg projects already use them all, make, autoconf, automake,<br>
> libtool and pkg-config, so let's at least count them all and<br>
<br>
pkg-config only becuase some external packages provide only pkg-config<br>
stuff.<br>
<br>
> When I saw libgpg-error master publishes pkg-config metadata, I was<br>
> very happy, as it does show some new openness, as I know your point of<br>
> view. You also stated that you want pkg-config to be second class<br>
> option, so I introduced the enable_pkg_config flag with default no, to<br>
<br>
That is the whole poing with avoiding a second build system.  People<br>
will soon start to use that alternative system and as maintainers we run<br>
in all kind of problems because it is assumed tha this is a supported<br>
way of using a library.  <br>
<br>
> keep backward compatibility. Using the pkg-config resolves issues of<br>
> multilib and cross-compile without need to modify the existing<br>
<br>
I still can't see why this is the case.  SYSROOT support is in our<br>
libraries since 2014 and makes it really easy to use a cross-build<br>
library: The foo-config script is run as $SYSROOT/bin/foo-config where<br>
the make install of the library has stored it.<br>
<br>
> 4. Per each component a config script is being maintained.<br>
<br>
Which is as easy as writing a pc file if not easier.<br>
<br>
> 5. The script is different per project.<br>
<br>
Sure, it describes the configuraion.<br>
<br>
> 6. In libgpg-error master the script is a wrapper on top of pkg-config<br>
> metadata which implies that the pkg-config metadata is formally<br>
> maintained.<br>
<br>
That is a technical detail on how the "second class citizen" foo.pc is<br>
implemented.<br>
<br>
> 8. pkg-config and pkg.m4 are already used by the following projects:<br>
> $ find . -name 'pkg.m4' |  sort<br>
> ./gnupg/m4/pkg.m4<br>
> ./gpgme/m4/pkg.m4<br>
> ./pinentry/m4/pkg.m4<br>
<br>
As well as dozens of other m4 files to test for system features.<br>
<br>
> the existing script. I do not see a difference between pkg-config and<br>
> script:<br>
> a. it can detect a package based on component version expression<br>
<br>
But that is all what you get.  A script is much more powerful than a<br>
static description language and the script interpreter is a standard<br>
Unix tool on _all_ Unix platforms.  In contrast pgk-config requires to<br>
build and install an extra tool before you can start.<br>
<br>
> c. if a severe ABI breakage is happening project can modify the name<br>
> of the metadata for side-by-side or even install multiple metadata<br>
> each with different setting<br>
<br>
Changing the project name to declare an ABI break.  There are better<br>
ways.  In fact pkg-config could also support this by not only tracking a<br>
version but also an ABI counter.  AFAIK, it does not do that.<br>
<br>
>> foo-config) stuff makes a lot of sense.  For libraries with a maintained<br>
>> API and ABI a simpler, more portable but also harder to initially create<br>
>> dedicated config file is a cleaner approach.<br>
><br>
> I do not understand this argument, I will appreciate an example.<br>
<br>
If you look at really old foo-config scripts (they were introduced by<br>
Gtk+) you will see a lot of checks done by those scripts to cope with<br>
the fact that developers did not know how to properly design and<br>
maintain libraries.  The foo-config scripts tried to detect that and<br>
warned the developer/user.  Given the complexity of those scripts it was<br>
natural to unify that and we finally got to pkg-config.  Large projects<br>
like GNOME or KDE put a lot of code in libraries and view them similar<br>
as programs and change the as they like.  Those libraries are not<br>
re-usable but other software unless this other software's authors want<br>
to track the development of the umbrella project of a used library.  In<br>
contrast other libraries are written in a way to make sure that other<br>
software can rely on the interface of such a library.  For those<br>
libraries it is a negligible effort to maintain even a complicated<br>
foo-config script compared to what work is needed for all the other<br>
interface maintenance.<br>
<br>
> 3. for cross-compile, install these config scripts outside of the<br>
> sysroot, as it makes no sense to execute anything from sysroot of<br>
> other architecture<br>
<br>
As explained above I take another view here.  Running config scripts is<br>
portable accorsoo platforms.<br>
<br>
> 4. for cross-compile, the tool need to be familiar with sysroot<br>
> concept to output paths relative to sysroot<br>
<br>
Agreed and implemented.  Where do you see the bug in the SYSROOT support<br>
of our foo-configs?<br>
<br>
> I only expected to trigger discussion, I did not expected you just<br>
> merge it as is :)<br>
<br>
Worked.<br>
<br>
<br>
Salam-Shalom,<br>
<br>
   Werner<br>
<br>
-- <br>
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.<br>
</blockquote></div>