SYSROOT vs --with-xxx-prefix

[Alon Bar-Lev]

On Wed, Oct 10, 2018 at 7:51 AM Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>
> 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

Patch is available[1].

BTW: I am unsure that you aware aware, but when using pkg.m4 and these
PKG_CHECK_* macros, if the pkg-config utility is not installed, it
simply execute the if-not-found clause, so this does not introduce
hard dependency, it simply falls back to the current logic.

[1] https://github.com/alonbl/libgpg-error/pull/1/files?utf8=%E2%9C%93&diff=unified&w=1


>
> > > 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