SYSROOT vs --with-xxx-prefix

Alon Bar-Lev alon.barlev at gmail.com
Wed Oct 10 06:51:31 CEST 2018


On Wed, Oct 10, 2018 at 5:18 AM NIIBE Yutaka <gniibe at fsij.org> wrote:
>
> Hello,
>
> Thanks for yor try.  Please have a lock at gnupg/doc/HACKING [0],
> and submit your change to dev.gnupg.org or this maling list.
> Before your submission, I'd suggest to minimize your change
> (e.g. don't include indentation change).
>
> Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> > libgpg-error and found out that you already support pkg-config and
> > converted the config script to delegate calls to the pkg-config.
>
> No, the config script (gpg-error-config) never delegates to pkg-config.
> It *does* handle the gpg-error.pc file by itself.
> We share the gpg-error.pc file between gpg-error-config and pkg-config,
> and I'd like to keep deviation by gpg-error-config as small as possible.

Yes, I should have phrased it better, it is great you begin support
other libraries to use pkg-config, this is a great change in spirit.

> Well, I repeat: GnuPG build process never depends on pkg-config.

This is not entirely true you do have projects that use pkg-config,
just not via the pkg.m4 macro for some reason.
Providing pkg-config fixes issues for all packages outside of the
gnupg project - that's great.
However, the entire problem is that the gnupg project packages
continue to use these proprietary config script and try to search for
them during build, this tends to break, for example:
1. configure script cannot find these in path when building cross
compile, autoconf shoud be modified to explicitly look for these at
SYSROOT/bin:SYSROOT/usr/bin
2. multilib cannot use a single script, you need to install these
scripts as HOST-xxx-config and use AC_PATH_TOOL instead of
AC_PATH_RPOG

However, using pkg-config do not have these issues, so using it
enables you to bypass these issues without fixing them.
I provided a clean way to use pkg-config if available and if not
fallback to current proprietary mechanism, it takes nothing from the
existing process, if user do not explicitly ask for config script and
pkg-config is not available on system the current process remains.

Will you feel better if we have --enable-pkg-config in autoconf
disabled by default, and can be enabled by downstream that support
pkg-config?
Logic: --enable-pkg-config - use pkg-config instead of proprietary
mechanism, this is as simple as and for sure do not take anything from
anyone if not explicitly enabled:

if test x"${enable_pkg_config}" = xyes; then
   PKG_CHECK_MODULES([GPG_ERROR], [gpg-error >=
$min_gpg_error_version], , [enable_pkg_config=no])
   PKG_CHECK_VAR([GPG_ERROR_MT_CFLAGS], [gpg-error], [mtcflags])
   PKG_CHECK_VAR([GPG_ERROR_MT_LIBS], [gpg-error], [mtlibs])
fi
if test x"${enable_pkg_config}" = xno; then
  # current code
fi

> > There are some gaps that can be solved. Then the same can be
> > replicated to all other projects.
>
> Today, I push two changes:
>
>     gpg-error-config: Fix the place of *.pc (for multilib).
>     9f71b28dcb38e1d5d9001692e2f64009396aaf9b
>
>     gpg-error-config: Add PKG_CONFIG_SYSROOT_DIR support.
>     6167f3c461a4e53ccc5af620cdbfa28bfa9234f5
>
> The first one is what you pointed out.
> The second one is supporting cross build.

Thanks!
But this is not enough as long as these config scripts are being used.
Alon



More information about the Gnupg-devel mailing list