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

[Alon Bar-Lev]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181020/adc8e89b/attachment.html>