[PATCH Libgpg-error] gpg-error.m4: support pkg-config

[Alon Bar-Lev]

Hello Werner,
I will appreciate if we can keep this thread alive to help us improve
the usability of the build system.
Thanks!

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