Mailing List Archive

[PATCH Libgpg-error] gpg-error.m4: support pkg-config
* m4/pkg.m4: New.
* src/gpg-error.m4: use pkg-config if enabled.

--

libgpg-error installs pkg-config configuration file, it even become the
source of truth for the gpg-error-config script.

All gpg-error.m4 consumers can leverage pkg-config as well. In order to
keep backward compatibility, the pkg-config variant will be used only if
enable_pkg_config is set to yes. if pkg-config not found or pkg-config
configuration is missing it will fallback to current implementation.

Apart of being a standard/popular method, pkg-config has advantages over
using executable config scripts:

* Simplicity, built for the task.

* Good integration into autoconf using the pkg.m4 macros, enables the
detection of pkg-config, fallback if missing and handle the
interaction, including override settings by environment.

* Support for multilib configurations as configuration is installed per
library setup, unlike a common script that is installed at bindir.

* Cross-compile support, support sysroot and does not require to execute
anything from sysroot.

Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>
---
m4/pkg.m4 | 343 +++++++++++++++++++++++++++++++++++++++++++++++
src/gpg-error.m4 | 149 +++++++++++---------
2 files changed, 426 insertions(+), 66 deletions(-)
create mode 100644 m4/pkg.m4

diff --git a/src/gpg-error.m4 b/src/gpg-error.m4
index 0564219..d3a0ad7 100644
--- a/src/gpg-error.m4
+++ b/src/gpg-error.m4
@@ -26,6 +26,7 @@ dnl is added to the gpg_config_script_warn variable.
dnl
AC_DEFUN([AM_PATH_GPG_ERROR],
[ AC_REQUIRE([AC_CANONICAL_HOST])
+ AC_REQUIRE([PKG_PROG_PKG_CONFIG])
gpg_error_config_prefix=""
dnl --with-libgpg-error-prefix=PFX is the preferred name for this option,
dnl since that is consistent with how our three siblings use the directory/
@@ -40,64 +41,79 @@ AC_DEFUN([AM_PATH_GPG_ERROR],
dnl but do not document this old, inconsistently-named option.
AC_ARG_WITH(gpg-error-prefix,,
[gpg_error_config_prefix="$withval"])
+ min_gpg_error_version=ifelse([$1], ,0.0,$1)

- if test x"${GPG_ERROR_CONFIG}" = x ; then
- if test x"${gpg_error_config_prefix}" != x ; then
- GPG_ERROR_CONFIG="${gpg_error_config_prefix}/bin/gpg-error-config"
- else
- case "${SYSROOT}" in
- /*)
- if test -x "${SYSROOT}/bin/gpg-error-config" ; then
- GPG_ERROR_CONFIG="${SYSROOT}/bin/gpg-error-config"
- fi
- ;;
- '')
- ;;
- *)
- AC_MSG_WARN([Ignoring \$SYSROOT as it is not an absolute path.])
- ;;
- esac
- fi
+ gpg_error_use_config=yes
+ if test x"${enable_pkg_config}" = xyes; then
+ PKG_CHECK_MODULES(
+ [GPG_ERROR],
+ [gpg-error >= $min_gpg_error_version],
+ [
+ gpg_error_use_config=no
+ PKG_CHECK_VAR([GPG_ERROR_MT_CFLAGS], [gpg-error], [mtcflags])
+ PKG_CHECK_VAR([GPG_ERROR_MT_LIBS], [gpg-error], [mtlibs])
+ ],
+ [:]
+ )
fi

- AC_PATH_PROG(GPG_ERROR_CONFIG, gpg-error-config, no)
- min_gpg_error_version=ifelse([$1], ,0.0,$1)
- AC_MSG_CHECKING(for GPG Error - version >= $min_gpg_error_version)
- ok=no
- if test "$GPG_ERROR_CONFIG" != "no" \
- && test -f "$GPG_ERROR_CONFIG" ; then
- req_major=`echo $min_gpg_error_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
- req_minor=`echo $min_gpg_error_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
- gpg_error_config_version=`$GPG_ERROR_CONFIG $gpg_error_config_args --version`
- major=`echo $gpg_error_config_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
- minor=`echo $gpg_error_config_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
- if test "$major" -gt "$req_major"; then
- ok=yes
- else
- if test "$major" -eq "$req_major"; then
- if test "$minor" -ge "$req_minor"; then
- ok=yes
- fi
- fi
+ if test x"${gpg_error_use_config}" = xyes; then
+ if test x"${GPG_ERROR_CONFIG}" = x ; then
+ if test x"${gpg_error_config_prefix}" != x ; then
+ GPG_ERROR_CONFIG="${gpg_error_config_prefix}/bin/gpg-error-config"
+ else
+ case "${SYSROOT}" in
+ /*)
+ if test -x "${SYSROOT}/bin/gpg-error-config" ; then
+ GPG_ERROR_CONFIG="${SYSROOT}/bin/gpg-error-config"
+ fi
+ ;;
+ '')
+ ;;
+ *)
+ AC_MSG_WARN([Ignoring \$SYSROOT as it is not an absolute path.])
+ ;;
+ esac
+ fi
fi
- fi
- if test $ok = yes; then
- GPG_ERROR_CFLAGS=`$GPG_ERROR_CONFIG $gpg_error_config_args --cflags`
- GPG_ERROR_LIBS=`$GPG_ERROR_CONFIG $gpg_error_config_args --libs`
- GPG_ERROR_MT_CFLAGS=`$GPG_ERROR_CONFIG $gpg_error_config_args --variable=mtcflags 2>/dev/null`
- GPG_ERROR_MT_CFLAGS="$GPG_ERROR_CFLAGS${GPG_ERROR_CFLAGS:+ }$GPG_ERROR_MT_CFLAGS"
- GPG_ERROR_MT_LIBS=`$GPG_ERROR_CONFIG $gpg_error_config_args --variable=mtlibs 2>/dev/null`
- GPG_ERROR_MT_LIBS="$GPG_ERROR_LIBS${GPG_ERROR_LIBS:+ }$GPG_ERROR_MT_LIBS"
- AC_MSG_RESULT([yes ($gpg_error_config_version)])
- ifelse([$2], , :, [$2])
- gpg_error_config_host=`$GPG_ERROR_CONFIG $gpg_error_config_args --variable=host 2>/dev/null || echo none`
- if test x"$gpg_error_config_host" != xnone ; then
- if test x"$gpg_error_config_host" != x"$host" ; then
- AC_MSG_WARN([.[.
+
+ AC_PATH_PROG(GPG_ERROR_CONFIG, gpg-error-config, no)
+ AC_MSG_CHECKING(for GPG Error - version >= $min_gpg_error_version)
+ ok=no
+ if test "$GPG_ERROR_CONFIG" != "no" \
+ && test -f "$GPG_ERROR_CONFIG" ; then
+ req_major=`echo $min_gpg_error_version | \
+ sed 's/\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
+ req_minor=`echo $min_gpg_error_version | \
+ sed 's/\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
+ gpg_error_config_version=`$GPG_ERROR_CONFIG $gpg_error_config_args --version`
+ major=`echo $gpg_error_config_version | \
+ sed 's/\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
+ minor=`echo $gpg_error_config_version | \
+ sed 's/\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
+ if test "$major" -gt "$req_major"; then
+ ok=yes
+ else
+ if test "$major" -eq "$req_major"; then
+ if test "$minor" -ge "$req_minor"; then
+ ok=yes
+ fi
+ fi
+ fi
+ fi
+ if test $ok = yes; then
+ GPG_ERROR_CFLAGS=`$GPG_ERROR_CONFIG $gpg_error_config_args --cflags`
+ GPG_ERROR_LIBS=`$GPG_ERROR_CONFIG $gpg_error_config_args --libs`
+ GPG_ERROR_MT_CFLAGS=`$GPG_ERROR_CONFIG $gpg_error_config_args --variable=mtcflags 2>/dev/null`
+ GPG_ERROR_MT_CFLAGS="$GPG_ERROR_CFLAGS${GPG_ERROR_CFLAGS:+ }$GPG_ERROR_MT_CFLAGS"
+ GPG_ERROR_MT_LIBS=`$GPG_ERROR_CONFIG $gpg_error_config_args --variable=mtlibs 2>/dev/null`
+ GPG_ERROR_MT_LIBS="$GPG_ERROR_LIBS${GPG_ERROR_LIBS:+ }$GPG_ERROR_MT_LIBS"
+ AC_MSG_RESULT([yes ($gpg_error_config_version)])
+ ifelse([$2], , :, [$2])
+ gpg_error_config_host=`$GPG_ERROR_CONFIG $gpg_error_config_args --variable=host 2>/dev/null || echo none`
+ if test x"$gpg_error_config_host" != xnone ; then
+ if test x"$gpg_error_config_host" != x"$host" ; then
+ AC_MSG_WARN([.[.
***
*** The config script $GPG_ERROR_CONFIG was
*** built for $gpg_error_config_host and thus may not match the
@@ -105,19 +121,20 @@ AC_DEFUN([AM_PATH_GPG_ERROR],
*** You may want to use the configure option --with-libgpg-error-prefix
*** to specify a matching config script or use \$SYSROOT.
***]])
- gpg_config_script_warn="$gpg_config_script_warn libgpg-error"
+ gpg_config_script_warn="$gpg_config_script_warn libgpg-error"
+ fi
fi
+ else
+ GPG_ERROR_CFLAGS=""
+ GPG_ERROR_LIBS=""
+ GPG_ERROR_MT_CFLAGS=""
+ GPG_ERROR_MT_LIBS=""
+ AC_MSG_RESULT(no)
+ ifelse([$3], , :, [$3])
fi
- else
- GPG_ERROR_CFLAGS=""
- GPG_ERROR_LIBS=""
- GPG_ERROR_MT_CFLAGS=""
- GPG_ERROR_MT_LIBS=""
- AC_MSG_RESULT(no)
- ifelse([$3], , :, [$3])
+ AC_SUBST(GPG_ERROR_CFLAGS)
+ AC_SUBST(GPG_ERROR_LIBS)
+ AC_SUBST(GPG_ERROR_MT_CFLAGS)
+ AC_SUBST(GPG_ERROR_MT_LIBS)
fi
- AC_SUBST(GPG_ERROR_CFLAGS)
- AC_SUBST(GPG_ERROR_LIBS)
- AC_SUBST(GPG_ERROR_MT_CFLAGS)
- AC_SUBST(GPG_ERROR_MT_LIBS)
])
diff --git a/m4/pkg.m4 b/m4/pkg.m4
new file mode 100644
index 0000000..ef61d61
--- /dev/null
+++ b/m4/pkg.m4
@@ -0,0 +1,343 @@
+# pkg.m4 - Macros to locate and utilise pkg-config. -*- Autoconf -*-
+# serial 11 (pkg-config-0.29.1)
+
+dnl Copyright © 2004 Scott James Remnant <scott@netsplit.com>.
+dnl Copyright © 2012-2015 Dan Nicholson <dbn.lists@gmail.com>
+dnl
+dnl This program is free software; you can redistribute it and/or modify
+dnl it under the terms of the GNU General Public License as published by
+dnl the Free Software Foundation; either version 2 of the License, or
+dnl (at your option) any later version.
+dnl
+dnl This program is distributed in the hope that it will be useful, but
+dnl WITHOUT ANY WARRANTY; without even the implied warranty of
+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+dnl General Public License for more details.
+dnl
+dnl You should have received a copy of the GNU General Public License
+dnl along with this program; if not, write to the Free Software
+dnl Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+dnl 02111-1307, USA.
+dnl
+dnl As a special exception to the GNU General Public License, if you
+dnl distribute this file as part of a program that contains a
+dnl configuration script generated by Autoconf, you may include it under
+dnl the same distribution terms that you use for the rest of that
+dnl program.
+
+dnl PKG_PREREQ(MIN-VERSION)
+dnl -----------------------
+dnl Since: 0.29
+dnl
+dnl Verify that the version of the pkg-config macros are at least
+dnl MIN-VERSION. Unlike PKG_PROG_PKG_CONFIG, which checks the user's
+dnl installed version of pkg-config, this checks the developer's version
+dnl of pkg.m4 when generating configure.
+dnl
+dnl To ensure that this macro is defined, also add:
+dnl m4_ifndef([PKG_PREREQ],
+dnl [m4_fatal([must install pkg-config 0.29 or later before running autoconf/autogen])])
+dnl
+dnl See the "Since" comment for each macro you use to see what version
+dnl of the macros you require.
+m4_defun([PKG_PREREQ],
+[m4_define([PKG_MACROS_VERSION], [0.29.1])
+m4_if(m4_version_compare(PKG_MACROS_VERSION, [$1]), -1,
+ [m4_fatal([pkg.m4 version $1 or higher is required but ]PKG_MACROS_VERSION[ found])])
+])dnl PKG_PREREQ
+
+dnl PKG_PROG_PKG_CONFIG([MIN-VERSION])
+dnl ----------------------------------
+dnl Since: 0.16
+dnl
+dnl Search for the pkg-config tool and set the PKG_CONFIG variable to
+dnl first found in the path. Checks that the version of pkg-config found
+dnl is at least MIN-VERSION. If MIN-VERSION is not specified, 0.9.0 is
+dnl used since that's the first version where most current features of
+dnl pkg-config existed.
+AC_DEFUN([PKG_PROG_PKG_CONFIG],
+[m4_pattern_forbid([^_?PKG_[A-Z_]+$])
+m4_pattern_allow([^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$])
+m4_pattern_allow([^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|DEBUG_SPEW)$])
+AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility])
+AC_ARG_VAR([PKG_CONFIG_PATH], [directories to add to pkg-config's search path])
+AC_ARG_VAR([PKG_CONFIG_LIBDIR], [path overriding pkg-config's built-in search path])
+
+if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then
+ AC_PATH_TOOL([PKG_CONFIG], [pkg-config])
+fi
+if test -n "$PKG_CONFIG"; then
+ _pkg_min_version=m4_default([$1], [0.9.0])
+ AC_MSG_CHECKING([pkg-config is at least version $_pkg_min_version])
+ if $PKG_CONFIG --atleast-pkgconfig-version $_pkg_min_version; then
+ AC_MSG_RESULT([yes])
+ else
+ AC_MSG_RESULT([no])
+ PKG_CONFIG=""
+ fi
+fi[]dnl
+])dnl PKG_PROG_PKG_CONFIG
+
+dnl PKG_CHECK_EXISTS(MODULES, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
+dnl -------------------------------------------------------------------
+dnl Since: 0.18
+dnl
+dnl Check to see whether a particular set of modules exists. Similar to
+dnl PKG_CHECK_MODULES(), but does not set variables or print errors.
+dnl
+dnl Please remember that m4 expands AC_REQUIRE([PKG_PROG_PKG_CONFIG])
+dnl only at the first occurence in configure.ac, so if the first place
+dnl it's called might be skipped (such as if it is within an "if", you
+dnl have to call PKG_CHECK_EXISTS manually
+AC_DEFUN([PKG_CHECK_EXISTS],
+[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl
+if test -n "$PKG_CONFIG" && \
+ AC_RUN_LOG([$PKG_CONFIG --exists --print-errors "$1"]); then
+ m4_default([$2], [:])
+m4_ifvaln([$3], [else
+ $3])dnl
+fi])
+
+dnl _PKG_CONFIG([VARIABLE], [COMMAND], [MODULES])
+dnl ---------------------------------------------
+dnl Internal wrapper calling pkg-config via PKG_CONFIG and setting
+dnl pkg_failed based on the result.
+m4_define([_PKG_CONFIG],
+[if test -n "$$1"; then
+ pkg_cv_[]$1="$$1"
+ elif test -n "$PKG_CONFIG"; then
+ PKG_CHECK_EXISTS([$3],
+ [pkg_cv_[]$1=`$PKG_CONFIG --[]$2 "$3" 2>/dev/null`
+ test "x$?" != "x0" && pkg_failed=yes ],
+ [pkg_failed=yes])
+ else
+ pkg_failed=untried
+fi[]dnl
+])dnl _PKG_CONFIG
+
+dnl _PKG_SHORT_ERRORS_SUPPORTED
+dnl ---------------------------
+dnl Internal check to see if pkg-config supports short errors.
+AC_DEFUN([_PKG_SHORT_ERRORS_SUPPORTED],
+[AC_REQUIRE([PKG_PROG_PKG_CONFIG])
+if $PKG_CONFIG --atleast-pkgconfig-version 0.20; then
+ _pkg_short_errors_supported=yes
+else
+ _pkg_short_errors_supported=no
+fi[]dnl
+])dnl _PKG_SHORT_ERRORS_SUPPORTED
+
+
+dnl PKG_CHECK_MODULES(VARIABLE-PREFIX, MODULES, [ACTION-IF-FOUND],
+dnl [ACTION-IF-NOT-FOUND])
+dnl --------------------------------------------------------------
+dnl Since: 0.4.0
+dnl
+dnl Note that if there is a possibility the first call to
+dnl PKG_CHECK_MODULES might not happen, you should be sure to include an
+dnl explicit call to PKG_PROG_PKG_CONFIG in your configure.ac
+AC_DEFUN([PKG_CHECK_MODULES],
+[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl
+AC_ARG_VAR([$1][_CFLAGS], [C compiler flags for $1, overriding pkg-config])dnl
+AC_ARG_VAR([$1][_LIBS], [linker flags for $1, overriding pkg-config])dnl
+
+pkg_failed=no
+AC_MSG_CHECKING([for $1])
+
+_PKG_CONFIG([$1][_CFLAGS], [cflags], [$2])
+_PKG_CONFIG([$1][_LIBS], [libs], [$2])
+
+m4_define([_PKG_TEXT], [Alternatively, you may set the environment variables $1[]_CFLAGS
+and $1[]_LIBS to avoid the need to call pkg-config.
+See the pkg-config man page for more details.])
+
+if test $pkg_failed = yes; then
+ AC_MSG_RESULT([no])
+ _PKG_SHORT_ERRORS_SUPPORTED
+ if test $_pkg_short_errors_supported = yes; then
+ $1[]_PKG_ERRORS=`$PKG_CONFIG --short-errors --print-errors --cflags --libs "$2" 2>&1`
+ else
+ $1[]_PKG_ERRORS=`$PKG_CONFIG --print-errors --cflags --libs "$2" 2>&1`
+ fi
+ # Put the nasty error message in config.log where it belongs
+ echo "$$1[]_PKG_ERRORS" >&AS_MESSAGE_LOG_FD
+
+ m4_default([$4], [.AC_MSG_ERROR(
+[.Package requirements ($2) were not met:
+
+$$1_PKG_ERRORS
+
+Consider adjusting the PKG_CONFIG_PATH environment variable if you
+installed software in a non-standard prefix.
+
+_PKG_TEXT])[]dnl
+ ])
+elif test $pkg_failed = untried; then
+ AC_MSG_RESULT([no])
+ m4_default([$4], [.AC_MSG_FAILURE(
+[.The pkg-config script could not be found or is too old. Make sure it
+is in your PATH or set the PKG_CONFIG environment variable to the full
+path to pkg-config.
+
+_PKG_TEXT
+
+To get pkg-config, see <http://pkg-config.freedesktop.org/>.])[]dnl
+ ])
+else
+ $1[]_CFLAGS=$pkg_cv_[]$1[]_CFLAGS
+ $1[]_LIBS=$pkg_cv_[]$1[]_LIBS
+ AC_MSG_RESULT([yes])
+ $3
+fi[]dnl
+])dnl PKG_CHECK_MODULES
+
+
+dnl PKG_CHECK_MODULES_STATIC(VARIABLE-PREFIX, MODULES, [ACTION-IF-FOUND],
+dnl [ACTION-IF-NOT-FOUND])
+dnl ---------------------------------------------------------------------
+dnl Since: 0.29
+dnl
+dnl Checks for existence of MODULES and gathers its build flags with
+dnl static libraries enabled. Sets VARIABLE-PREFIX_CFLAGS from --cflags
+dnl and VARIABLE-PREFIX_LIBS from --libs.
+dnl
+dnl Note that if there is a possibility the first call to
+dnl PKG_CHECK_MODULES_STATIC might not happen, you should be sure to
+dnl include an explicit call to PKG_PROG_PKG_CONFIG in your
+dnl configure.ac.
+AC_DEFUN([PKG_CHECK_MODULES_STATIC],
+[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl
+_save_PKG_CONFIG=$PKG_CONFIG
+PKG_CONFIG="$PKG_CONFIG --static"
+PKG_CHECK_MODULES($@)
+PKG_CONFIG=$_save_PKG_CONFIG[]dnl
+])dnl PKG_CHECK_MODULES_STATIC
+
+
+dnl PKG_INSTALLDIR([DIRECTORY])
+dnl -------------------------
+dnl Since: 0.27
+dnl
+dnl Substitutes the variable pkgconfigdir as the location where a module
+dnl should install pkg-config .pc files. By default the directory is
+dnl $libdir/pkgconfig, but the default can be changed by passing
+dnl DIRECTORY. The user can override through the --with-pkgconfigdir
+dnl parameter.
+AC_DEFUN([PKG_INSTALLDIR],
+[m4_pushdef([pkg_default], [m4_default([$1], ['${libdir}/pkgconfig'])])
+m4_pushdef([pkg_description],
+ [pkg-config installation directory @<:@]pkg_default[@:>@])
+AC_ARG_WITH([pkgconfigdir],
+ [AS_HELP_STRING([--with-pkgconfigdir], pkg_description)],,
+ [with_pkgconfigdir=]pkg_default)
+AC_SUBST([pkgconfigdir], [$with_pkgconfigdir])
+m4_popdef([pkg_default])
+m4_popdef([pkg_description])
+])dnl PKG_INSTALLDIR
+
+
+dnl PKG_NOARCH_INSTALLDIR([DIRECTORY])
+dnl --------------------------------
+dnl Since: 0.27
+dnl
+dnl Substitutes the variable noarch_pkgconfigdir as the location where a
+dnl module should install arch-independent pkg-config .pc files. By
+dnl default the directory is $datadir/pkgconfig, but the default can be
+dnl changed by passing DIRECTORY. The user can override through the
+dnl --with-noarch-pkgconfigdir parameter.
+AC_DEFUN([PKG_NOARCH_INSTALLDIR],
+[m4_pushdef([pkg_default], [m4_default([$1], ['${datadir}/pkgconfig'])])
+m4_pushdef([pkg_description],
+ [pkg-config arch-independent installation directory @<:@]pkg_default[@:>@])
+AC_ARG_WITH([noarch-pkgconfigdir],
+ [AS_HELP_STRING([--with-noarch-pkgconfigdir], pkg_description)],,
+ [with_noarch_pkgconfigdir=]pkg_default)
+AC_SUBST([noarch_pkgconfigdir], [$with_noarch_pkgconfigdir])
+m4_popdef([pkg_default])
+m4_popdef([pkg_description])
+])dnl PKG_NOARCH_INSTALLDIR
+
+
+dnl PKG_CHECK_VAR(VARIABLE, MODULE, CONFIG-VARIABLE,
+dnl [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
+dnl -------------------------------------------
+dnl Since: 0.28
+dnl
+dnl Retrieves the value of the pkg-config variable for the given module.
+AC_DEFUN([PKG_CHECK_VAR],
+[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl
+AC_ARG_VAR([$1], [value of $3 for $2, overriding pkg-config])dnl
+
+_PKG_CONFIG([$1], [variable="][$3]["], [$2])
+AS_VAR_COPY([$1], [pkg_cv_][$1])
+
+AS_VAR_IF([$1], [""], [$5], [$4])dnl
+])dnl PKG_CHECK_VAR
+
+dnl PKG_WITH_MODULES(VARIABLE-PREFIX, MODULES,
+dnl [ACTION-IF-FOUND],[ACTION-IF-NOT-FOUND],
+dnl [DESCRIPTION], [DEFAULT])
+dnl ------------------------------------------
+dnl
+dnl Prepare a "--with-" configure option using the lowercase
+dnl [VARIABLE-PREFIX] name, merging the behaviour of AC_ARG_WITH and
+dnl PKG_CHECK_MODULES in a single macro.
+AC_DEFUN([PKG_WITH_MODULES],
+[
+m4_pushdef([with_arg], m4_tolower([$1]))
+
+m4_pushdef([description],
+ [m4_default([$5], [build with ]with_arg[ support])])
+
+m4_pushdef([def_arg], [m4_default([$6], [auto])])
+m4_pushdef([def_action_if_found], [AS_TR_SH([with_]with_arg)=yes])
+m4_pushdef([def_action_if_not_found], [AS_TR_SH([with_]with_arg)=no])
+
+m4_case(def_arg,
+ [yes],[m4_pushdef([with_without], [--without-]with_arg)],
+ [m4_pushdef([with_without],[--with-]with_arg)])
+
+AC_ARG_WITH(with_arg,
+ AS_HELP_STRING(with_without, description[ @<:@default=]def_arg[@:>@]),,
+ [AS_TR_SH([with_]with_arg)=def_arg])
+
+AS_CASE([$AS_TR_SH([with_]with_arg)],
+ [yes],[PKG_CHECK_MODULES([$1],[$2],$3,$4)],
+ [auto],[PKG_CHECK_MODULES([$1],[$2],
+ [m4_n([def_action_if_found]) $3],
+ [m4_n([def_action_if_not_found]) $4])])
+
+m4_popdef([with_arg])
+m4_popdef([description])
+m4_popdef([def_arg])
+
+])dnl PKG_WITH_MODULES
+
+dnl PKG_HAVE_WITH_MODULES(VARIABLE-PREFIX, MODULES,
+dnl [DESCRIPTION], [DEFAULT])
+dnl -----------------------------------------------
+dnl
+dnl Convenience macro to trigger AM_CONDITIONAL after PKG_WITH_MODULES
+dnl check._[VARIABLE-PREFIX] is exported as make variable.
+AC_DEFUN([PKG_HAVE_WITH_MODULES],
+[
+PKG_WITH_MODULES([$1],[$2],,,[$3],[$4])
+
+AM_CONDITIONAL([HAVE_][$1],
+ [test "$AS_TR_SH([with_]m4_tolower([$1]))" = "yes"])
+])dnl PKG_HAVE_WITH_MODULES
+
+dnl PKG_HAVE_DEFINE_WITH_MODULES(VARIABLE-PREFIX, MODULES,
+dnl [DESCRIPTION], [DEFAULT])
+dnl ------------------------------------------------------
+dnl
+dnl Convenience macro to run AM_CONDITIONAL and AC_DEFINE after
+dnl PKG_WITH_MODULES check. HAVE_[VARIABLE-PREFIX] is exported as make
+dnl and preprocessor variable.
+AC_DEFUN([PKG_HAVE_DEFINE_WITH_MODULES],
+[
+PKG_HAVE_WITH_MODULES([$1],[$2],[$3],[$4])
+
+AS_IF([test "$AS_TR_SH([with_]m4_tolower([$1]))" = "yes"],
+ [AC_DEFINE([HAVE_][$1], 1, [Enable ]m4_tolower([$1])[ support])])
+])dnl PKG_HAVE_DEFINE_WITH_MODULES
--
2.18.1


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
On Thu, 11 Oct 2018 20:27, alon.barlev@gmail.com said:

> * Simplicity, built for the task.

I cannot say that 145,517 source lines of code is a good indication of
simplicity (Debian's 0.29). Compare that to make which has 30,919 SLOC
and thus 21% of pkg-config. I know that pkg-config it comes with glib
included but for a bootstrapping tool this is quite excessive. In
particular when looking at the 45,000 SLOC of libgpg-error.

> * Good integration into autoconf using the pkg.m4 macros, enables the
> detection of pkg-config, fallback if missing and handle the
> interaction, including override settings by environment.

And still not way to indicate an API break. Pretty inflexible way to
add new configure options due to using its own syntax instead of
utilizing the standard glue scripting language on Unix.

Remember that it was build for large projects like GNOME where creating
new libs is so common that virtually nobody takes care of ABI/API
maintenance. For such an environment pkg-config (or the older larger
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.

> * Support for multilib configurations as configuration is installed per
> library setup, unlike a common script that is installed at bindir.

Multilib is a questionable feature as it introduced a third way to build
packages (native, cross, multilib). The major problem, here is that it
was been developed by the linux distros without integrating this in the
standard GNU toolchain or getting it properly upstream.

> * Cross-compile support, support sysroot and does not require to execute
> anything from sysroot.

It seems to have improved over the years. I remember well, how we
needed to patch around pkg-config when cross building larger systems for
Windows.

Please don't let us have such discussions in commit logs.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
On 2018-10-12 at 08:31 +0200, Werner Koch wrote:
> On Thu, 11 Oct 2018 20:27, alon.barlev@gmail.com said:
> > * Simplicity, built for the task.
>
> I cannot say that 145,517 source lines of code is a good indication of
> simplicity (Debian's 0.29). Compare that to make which has 30,919 SLOC
> and thus 21% of pkg-config. I know that pkg-config it comes with glib
> included but for a bootstrapping tool this is quite excessive. In
> particular when looking at the 45,000 SLOC of libgpg-error.

FreeBSD reimplemented the pkg-config API in a much simpler code-base,
back in 2011. AFAIK this is the tooling used by FreeBSD Ports for all
pkg-config stuff, so is pretty well reality-tested by now.

Port devel/pkgconf with repo https://github.com/pkgconf/pkgconf

% wc -l libpkgconf/**/*(.) cli/**/*(.) | tail -n 1
9152 total

One implementation is big, but that doesn't mean folks have to use that
one. If GnuPG can invoke external tooling, they can use pkgconf for
bootstrapping.

-Phil

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
On Fri, Oct 12, 2018 at 9:35 AM Werner Koch <wk@gnupg.org> wrote:
>
> On Thu, 11 Oct 2018 20:27, alon.barlev@gmail.com said:

Hi,

> > * Simplicity, built for the task.
>
> I cannot say that 145,517 source lines of code is a good indication of
> simplicity (Debian's 0.29). Compare that to make which has 30,919 SLOC
> and thus 21% of pkg-config. I know that pkg-config it comes with glib
> included but for a bootstrapping tool this is quite excessive. In
> particular when looking at the 45,000 SLOC of libgpg-error.

I am sure you know the following, but I must address you counting line
of codes... This is odd... feel free to skip the next story.

<< __STORY__
scripts were used to build programs, then realized that building
everything every time is a waste of time and resources, and scripts
became complex to address these concerns.
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
write proper make files, make files got complex and in most cases
implemented using wrong logic.
autoconf was introduced to generate files from templates based on
logic as it was difficult to add functional logic into make files.
automake was introduced to provide a simple method to generate make
files that actually work with less error prune syntax, supporting
dependency management, distribution, tests, conditionals and more.
When shared library were introduced, most people got it wrong as each
architecture had different technology (if any) and tweaks (RPATH,
SONAME), support test and post-install etc... make files become
complex once again.
libtool was introduced to simplify library (static and shared)
creation, addressing all concerns.
CFLAGS, LDFLAGS detection were not that simple as threading and other
compiler settings should have considered, it required additional logic
of detection which was not always aligned with the library best
practice.
These concerns could have been address using metadata or scripts, at
first there was no standard for metadata, so these programs that
required special settings, developed their own unique solutions.
pkg-config evolved as metadata usage. There are advantages of using
metadata based information, mainly the ability to provide tool
selection to manage the metadata, having consistent behavior among
packages, not running anything from sysroot - all is important to
downstream maintainer and anyone who try to build.
__STORY__

The gnupg projects already use them all, make, autoconf, automake,
libtool and pkg-config, so let's at least count them all and
understand why we use and reuse components that are shared between
projects.

Don't get me wrong, I truly respect the gnupg project and maintained
its packages for many years, however, after reached to more or less
stable feature-set and structure, it may be the time to address some
of the issues that downstream maintainer experience to make it easier
to use the packages is required use cases.

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
keep backward compatibility. Using the pkg-config resolves issues of
multilib and cross-compile without need to modify the existing
mechanism.

Some statistics:

1. Per component a non trivial specific m4 script is maintained.
2. The m4 script required by dependencies so it is distributed to
other components (aclocal auto install is not used), this create
additional maintenance effort.
3. Size of each:
$ n=0; for f in ./gpgme/src/gpgme.m4 ./libassuan/src/libassuan.m4
./libgcrypt/src/libgcrypt.m4 ./libgpg-error/src/gpg-error.m4
./libksba/src/ksba.m4; do l=$(cat $f | grep -v '^dnl' | wc -l); echo
$l $f; n=$(($n+$l)); done; echo $n total
265 ./gpgme/src/gpgme.m4
127 ./libassuan/src/libassuan.m4
128 ./libgcrypt/src/libgcrypt.m4
128 ./libgpg-error/src/gpg-error.m4
113 ./libksba/src/ksba.m4
761 total

4. Per each component a config script is being maintained.
5. The script is different per project.
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.
7. Size of scripts:
$ find . -name '*-config.in' | sort | xargs wc -l
139 ./libksba/src/ksba-config.in
134 ./libassuan/src/libassuan-config.in
189 ./libgcrypt/src/libgcrypt-config.in
103 ./libgpg-error/src/gpg-error-config.in
211 ./gpgme/src/gpgme-config.in
776 total

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

9. Size of the pkg.m4 is smaller than the usage of component m4, and
reused for all cases of dependency detection:
$ cat m4/pkg.m4 | grep -v '^dnl' | wc -l
212

9. pkg-conf is an re-implementation of pkg-config:
$ find pkgconf-1.3.7/ -name '*.c' | xargs wc -l | grep total
6421 total

10. pkg-config is bloated because it has embedded glib:
$ find pkg-config-0.29.2/ -name '*.c' | xargs wc -l | grep total
123507 total
$ find pkg-config-0.29.2/ -name '*.c' | grep -v /glib | xargs wc -l | grep total
3386 total

> > * Good integration into autoconf using the pkg.m4 macros, enables the
> > detection of pkg-config, fallback if missing and handle the
> > interaction, including override settings by environment.
>
> And still not way to indicate an API break. Pretty inflexible way to
> add new configure options due to using its own syntax instead of
> utilizing the standard glue scripting language on Unix.

I am unsure I follow, I will appreciate if you provide an example from
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
b. if ABI version is required retrieve a specific variable out of the metadata.
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

What is missing?

> Remember that it was build for large projects like GNOME where creating
> new libs is so common that virtually nobody takes care of ABI/API
> maintenance. For such an environment pkg-config (or the older larger
> 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.

> > * Support for multilib configurations as configuration is installed per
> > library setup, unlike a common script that is installed at bindir.
>
> Multilib is a questionable feature as it introduced a third way to build
> packages (native, cross, multilib). The major problem, here is that it
> was been developed by the linux distros without integrating this in the
> standard GNU toolchain or getting it properly upstream.

On the contrary... I think. Each multilib configuration has a
different ${HOST} which complies with toolchain standards. The
autoconf AC_*_TOOL are designed to search for a tool at convention of
${HOST}-${TOOL}, which is aligned to the config script approach.
I already raised this issue in this recent thread, using multilib with
config script should:
1. install the tool as ${HOST}-${TOOL}, symlink this into ${TOOL} on
native if it makes sense.
2. use AC_*_TOOL to search for the tool
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
4. for cross-compile, the tool need to be familiar with sysroot
concept to output paths relative to sysroot

This is actually, the only point of why config script are "better"
supported, however, it require effort to do this right, and the gnupg
project should be fixed to follow the pattern.

However, using metadata instead of config scripts make it easier to
mange the settings as:
1. the tool is the tool which reads the metadata
2. nothing is running from the sysroot
3. the tool is familiar with sysroot

Once the gnupg projects provide pkg-config metadata, it is probably
easier to support these concerns properly within the pkg-config scope,
and providing a pkg-config alternative (enable_pkg_config=yes) while
preserving the current behavior for backward compatibility with past
use cases.

> > * Cross-compile support, support sysroot and does not require to execute
> > anything from sysroot.
>
> It seems to have improved over the years. I remember well, how we
> needed to patch around pkg-config when cross building larger systems for
> Windows.

Correct, it has been improved, it is not the best tool, but it is
sufficient in most of the cases. If you find a specific issue, I will
be happy to try and sort it out.

> Please don't let us have such discussions in commit logs.

I only expected to trigger discussion, I did not expected you just
merge it as is :)
If you want to proceed I will happily remove these comments.
I hope you will be in favor of supporting pkg-config as 2nd citizen in
gnupg projects.

Thanks for the discussion,
Alon

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
On Sat, 13 Oct 2018 00:07, alon.barlev@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.
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
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@gnupg.org> wrote:

> On Sat, 13 Oct 2018 00:07, alon.barlev@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.
>
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
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@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@gnupg.org> wrote:
>>
>> On Sat, 13 Oct 2018 00:07, alon.barlev@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.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> I will appreciate if we can keep this thread alive to help us improve
> the usability of the build system.

Not directly related to your purpose of introducing pkg-config, but
since it is strongly related, let me explain my work these days.

FWIW, I pushed my effort to offer .pc files by GnuPG libraries (npth,
libgpg-error, libgcrypt, libassuan, libksba, and ntbtls), and
to enable gpgrt-config handle .pc file.

Now, GnuPG master can be cross built with no SYSROOT nor --with-*-prefix
(given libraries of master installed), for major cases like Debian
multiarch (e.g., i686-linux-gnu on x86_64-linux-gnu), for Windows, and
possibly for Gentoo/Fedora/Arch -style multilib. I mean, just configure
with --host=* (and --libdir=*) option.

My focus for this change is for GnuPG build. There is no change for
GnuPG requirements.

From my viewpoint, it will be a kind of side effect when those libraries
can be used by pkg-config.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
On Wed, Oct 31, 2018 at 1:30 AM NIIBE Yutaka <gniibe@fsij.org> wrote:
>
> Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> > I will appreciate if we can keep this thread alive to help us improve
> > the usability of the build system.
>
> Not directly related to your purpose of introducing pkg-config, but
> since it is strongly related, let me explain my work these days.
>
> FWIW, I pushed my effort to offer .pc files by GnuPG libraries (npth,
> libgpg-error, libgcrypt, libassuan, libksba, and ntbtls), and
> to enable gpgrt-config handle .pc file.
>
> Now, GnuPG master can be cross built with no SYSROOT nor --with-*-prefix
> (given libraries of master installed), for major cases like Debian
> multiarch (e.g., i686-linux-gnu on x86_64-linux-gnu), for Windows, and
> possibly for Gentoo/Fedora/Arch -style multilib. I mean, just configure
> with --host=* (and --libdir=*) option.
>
> My focus for this change is for GnuPG build. There is no change for
> GnuPG requirements.
>
> From my viewpoint, it will be a kind of side effect when those libraries
> can be used by pkg-config.

Hi,

Thanks for the description.

However, this is not answering the concern raised in this thread, nor
this pkg-config support will be usable for the main consumer of gnupg
packages which are the gnupg project.

The build is broken as I described, exposing pkg-config to other
packages will not solve the issues of the gnupg component.

Please go over the last message and see that even if you want to use
config scripts these scripts should be prefixed by $HOST, should be
installed outside of $SYSROOT and be found by AC_TOOL_*.

I would like to understand why a simple mode of gnupg packages to
leverage the work you are doing of exposing pkg-config file should not
be applied. The patch I've created is a trivial patch that is enabled
only when user explicitly enable pkg-config support, this will solve
all the current issues of the build system without having to fix them
for these users who care (downstream maintainers, cross-compile
developers).

This thread is about modifying the build so that it will have an
option to use pkg-config instead of config scripts if downstream
maintainer chooses to.

Regards,
Alon

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> This thread is about modifying the build so that it will have an
> option to use pkg-config instead of config scripts if downstream
> maintainer chooses to.

I know.

I don't argue this point.

I pointed out that the important technical things (no use of
--with-*-prefix/SYSROOT with *-config scripts, to build GnuPG and its
related libraries) can be already achieved with no new dependency to
pkg-config. (I mean, gnupg in master. It's not yet applied
to stable branch.)

My point is, people don't need to use libraries' *-config scripts any
more, but only a single gpgrt-config script now.

In the past, there are *-config script from libraries, and for some
build environment, there are even prefixed versions for supported hosts,
like i686-linux-gnu-gpg-error-config and sh4-linux-gnu-libassuan-config.
Now, we only have a gpgrt-config.

Still *-config script in each library is not removed, so that it can
still support existing software, but it's no need any more when we build
gnupg master.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
Hello Werner,
Please don't let this thread die.
I will appreciate if we can come up with some solution that will be acceptable.
Thanks!
Alon

On Wed, Oct 31, 2018 at 8:14 AM NIIBE Yutaka <gniibe@fsij.org> wrote:
>
> Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> > This thread is about modifying the build so that it will have an
> > option to use pkg-config instead of config scripts if downstream
> > maintainer chooses to.
>
> I know.
>
> I don't argue this point.
>
> I pointed out that the important technical things (no use of
> --with-*-prefix/SYSROOT with *-config scripts, to build GnuPG and its
> related libraries) can be already achieved with no new dependency to
> pkg-config. (I mean, gnupg in master. It's not yet applied
> to stable branch.)
>
> My point is, people don't need to use libraries' *-config scripts any
> more, but only a single gpgrt-config script now.
>
> In the past, there are *-config script from libraries, and for some
> build environment, there are even prefixed versions for supported hosts,
> like i686-linux-gnu-gpg-error-config and sh4-linux-gnu-libassuan-config.
> Now, we only have a gpgrt-config.
>
> Still *-config script in each library is not removed, so that it can
> still support existing software, but it's no need any more when we build
> gnupg master.
> --

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
I am declaring this thread as MIA [Missing in action].
I am very sad that we cannot even properly discuss this.

On Tue, Nov 13, 2018 at 5:06 PM Alon Bar-Lev <alon.barlev@gmail.com> wrote:
>
> Hello Werner,
> Please don't let this thread die.
> I will appreciate if we can come up with some solution that will be acceptable.
> Thanks!
> Alon
>
> On Wed, Oct 31, 2018 at 8:14 AM NIIBE Yutaka <gniibe@fsij.org> wrote:
> >
> > Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> > > This thread is about modifying the build so that it will have an
> > > option to use pkg-config instead of config scripts if downstream
> > > maintainer chooses to.
> >
> > I know.
> >
> > I don't argue this point.
> >
> > I pointed out that the important technical things (no use of
> > --with-*-prefix/SYSROOT with *-config scripts, to build GnuPG and its
> > related libraries) can be already achieved with no new dependency to
> > pkg-config. (I mean, gnupg in master. It's not yet applied
> > to stable branch.)
> >
> > My point is, people don't need to use libraries' *-config scripts any
> > more, but only a single gpgrt-config script now.
> >
> > In the past, there are *-config script from libraries, and for some
> > build environment, there are even prefixed versions for supported hosts,
> > like i686-linux-gnu-gpg-error-config and sh4-linux-gnu-libassuan-config.
> > Now, we only have a gpgrt-config.
> >
> > Still *-config script in each library is not removed, so that it can
> > still support existing software, but it's no need any more when we build
> > gnupg master.
> > --

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
On Sun 2018-11-25 20:45:36 +0200, Alon Bar-Lev wrote:
> I am declaring this thread as MIA [Missing in action].
> I am very sad that we cannot even properly discuss this.

I agree, it's frustrating that this is not happening. There are many
reasons why pkg-config is common practice across the free software
ecosystem. It's not perfect, but it's widely understood. GnuPG's
continued idiosyncracy here makes it harder to work with than it needs
to be.

If the goal is to discourage developers from adopting GnuPG and related
packages, then the status quo is fine. But if the goal is facilitating
adoption, it would be good to have a clear conversation about strategy
and tactics to do so.

--dkg
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> it would be good to have a clear conversation about strategy and
> tactics to do so.

For pkg-config support, I think that I explained and show our way to do
so, but it seems that my points were not accepted unfortunately.

You can see my changes in GnuPG libraries, in the repo (master). In
next releases, we will provide .pc files by libgpg-error, npth,
libgcrypt, libassuan, libksba, ntbtls, and gpgme. Users of those
libraries will be able to use pkg-config if they want. Say, by using
pkg.m4 for autoconf to generate configure script.

For gpg-error.m4 and other m4 files, we don't have any idea to introduce
pkg-config support in that macro file, because we don't change the build
of GnuPG itself.

I think that use of pkg.m4 is superior, because it supports multiple
modules at once.

I think that there are two different things here; pkg-config support for
users of libraries, and change of GnuPG build.

For the latter, it should be conservative, because GnuPG is important
tool and it should be available earlier in the bootstrap process of
operating system.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
On Mon, Dec 3, 2018 at 12:27 AM NIIBE Yutaka <gniibe@fsij.org> wrote:
>
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> > it would be good to have a clear conversation about strategy and
> > tactics to do so.
>
> For pkg-config support, I think that I explained and show our way to do
> so, but it seems that my points were not accepted unfortunately.
>
> You can see my changes in GnuPG libraries, in the repo (master). In
> next releases, we will provide .pc files by libgpg-error, npth,
> libgcrypt, libassuan, libksba, ntbtls, and gpgme. Users of those
> libraries will be able to use pkg-config if they want. Say, by using
> pkg.m4 for autoconf to generate configure script.
>
> For gpg-error.m4 and other m4 files, we don't have any idea to introduce
> pkg-config support in that macro file, because we don't change the build
> of GnuPG itself.
>
> I think that use of pkg.m4 is superior, because it supports multiple
> modules at once.
>
> I think that there are two different things here; pkg-config support for
> users of libraries, and change of GnuPG build.
>
> For the latter, it should be conservative, because GnuPG is important
> tool and it should be available earlier in the bootstrap process of
> operating system.

We are discussing here the "change of GnuPG build" to support both
modes, the proprietary config files as default and in addition
pkg-config using pkg.m4 for these who wishes to use pkg-config to
build GnuPG components. This is trivial as I showed in this patch.

Thanks,
Alon

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> We are discussing here the "change of GnuPG build"

I know, you are. That resulted "we cannot even properly discuss this."

I explained a larger picture of our improvements. You ignore.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
On Mon, Dec 3, 2018 at 1:23 AM NIIBE Yutaka <gniibe@fsij.org> wrote:
>
> Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> > We are discussing here the "change of GnuPG build"
>
> I know, you are. That resulted "we cannot even properly discuss this."
>
> I explained a larger picture of our improvements. You ignore.

Please forgive me if I am ignoring anything. I read again the thread
and yet to understand the larger picture. Maybe I just keep missing
it.

Please explain again why not give an option for downstream to build
gnupg components using pkg-config, this does not take anything from
whoever wishes to continue to use current mode.

Pseudo code per each <library>.m4:

+if enable_pkg_config = yes:
+ use pkg-config via pkg.m4 macro to detect dependency flags
[usually oneliner]
+else:
use *-config macro to detect dependency flags
+endif

Why does this takes anything from the larger picture?

Thanks!
Alon

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
Hello,

Please accept my apologize if tone of my writing sounded too strong.
Perhaps, I (wrongly) recognized that my efforts were disregarded.

IIUC, you haven't try build of current master of GnuPG, with master of
npth, libgpg-error, libassuan, libgcrypt, libksba, and ntbtls, which
introduced .pc files for pkg-config compatibility. (Well, it is also
introduced to gpgme.)

I should have assumed that.

Let me explain in detail, even if it's TL;TR...

Or it is better to begin with a short answer, changing the order
of answer.

> Pseudo code per each <library>.m4:
>
> +if enable_pkg_config = yes:
> + use pkg-config via pkg.m4 macro to detect dependency flags
> [usually oneliner]
> +else:
> use *-config macro to detect dependency flags
> +endif
>
> Why does this takes anything from the larger picture?

It's OK for <library>'s user to do that, but we don't do that for GnuPG
build.

That's because it is not needed; In the current situation, it just
complicates things while adding no benefit.

Please understand that I don't deny your points what to be achieved by
such a change. It's done already in a different way, other than
introducing use of pkg-config.

* * *

Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> Please explain again why not give an option for downstream to build
> gnupg components using pkg-config, this does not take anything from
> whoever wishes to continue to use current mode.

For pkg-config compatibility, GnuPG libraries (npth, libgpg-error,
libassuan, libgcrypt, libksba, and ntbtls) introduced .pc files.

And we introduced a single script, named gpgrt-config, to handle .pc
files. This is a kind of cut-down version of pkg-config.

Now, other *-config scripts are only provided for backward
compatibility. (It is no use for new way of building GnuPG).

I did so, in order to separate static data (which can be described as
pkg-config style) and running script (which tends to easily introduce
peculiar incompatible things). I believe that by doing so, we can
maintain libraries of GnuPG, as friendly as possible to pkg-config.

Direct benefit of introducing .pc files are for users of those
libraries, they can use pkg-config for their applications (by "[usually
oneliner]" macro of pkg.m4), if they like. Instead of use of pkg.m4
macro, still, using old <library>.m4 with <library-specific>-config is
supported, and new <library>.m4 with gpgrt-config or
<library-specific>-config is also supported.

However, we don't use pkg-config for GnuPG build itself to configure
GnuPG libraries, while it uses pkg-config for optional external
libraries (sqlite and GnuTLS). We do so, because GnuPG should be
build-able without pkg-config. This is important requirement of GnuPG.

Optionally using pkg-config would make sense, if it doesn't add more
complexity for maintenance of GnuPG and if it can provide some benefit.
But... I think that newly introducing optional use of pkg-config for
GnuPG libraries just adds more unnecessary complexity for GnuPG build,
with no benefit.

While we try to keep the compatibility of pkg-config, the behavior of
pkg-config and gpgrt-config may be different, when pkg-config will
change. When behaviors are different, this should be fixed soonish, but
it may take longer without being noticed. When it occurs, the impact
for GnuPG build is... bad enough, since GnuPG will be not reproducible
in these two environments; The build with pkg-config (normal build) and
the build with pkg-config wil be different.


Although it's a side effect (I mean, it was not my own purpose
originally), my effort allows better support of GnuPG cross build in
various situations (multiarch in Debian, multilib for
Arch/Fedora/OpenSUSE, and straight cross build for Windows), just like
pkg-config can offer.

Actually, my effort greatly simplifies the situation of GnuPG cross
build, because we only use a single script.

In case of pkg-config, cross build is not supported by the tool itself,
but it is supported by some arrangement of distribution. For example,
in case of Debian, we have {HOST_ARCH}-pkg-config which links to
/usr/share/pkg-config-crosswrapper. This is not ideal situation, yet.

In old ways, there were {HOST_ARCH}-<library-specific>-config scripts
for GnuPG (too many!). Use of pkg-config can improve the situation to
have {HOST_ARCH}-pkg-config only. Now, there is only a single script of
gpgrt-config.

Speaking about less possibility thing, when/if we will have pkg-config
implementation (re-)written as portable AWK script, in future, we will
be able to use pkg-config directly. Then, we will be able to throw away
gpgrt-config.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
On Tue, Dec 4, 2018 at 2:54 AM NIIBE Yutaka <gniibe@fsij.org> wrote:
>
> Hello,
>
> Please accept my apologize if tone of my writing sounded too strong.
> Perhaps, I (wrongly) recognized that my efforts were disregarded.

Your efforts are not disregarded and are appreciated, 3rd party
components long waited for having pkg-config support for gnupg
components, now you have provided that, which is the base of taking
this farther into the gnupg build itself.

Based on your detailed description it seems like you do not understand
that us, downstream maintainers, and us, developers, need to cope with
a complex proprietary build system. I truly understand your point of
view, however, the larger picture is that we have many packages to
maintain in different scenarios and combinations, and gnupg build
system just make it harder to create a solution with no actual
functional benefit other than saying the pkg-config is not the idle
solution out there.

You truly believe that the build system of gnupg was simplified with
recent effort and you are probably right... however, this is not
enough when looking at the greater picture as it requires special
attention and does not comply with the best practices of build system
that we have worked so hard to reach.

Any proprietary build system, as simple as you may believe it is
introduce additional complexity in the grand plan. In this discussion,
I am not interested in taking anything from you, we can continue to
build and maintain gnupg packages without pkg-config, however, I would
like you to allow the option for downstream and developers who wishes
to use pkg-config to do so, this is a trivial effort to maintain now
that you provide pkg-config metadata.

Once again, I would like to see gnupg build system make both of us
happy, by default use your best/simplest/efficient build system, and
in addition provide pkg-config alternative for users who wishes to use
this method. It is trivial to support that, as I've shown in this
patch.

Regardless of using pkg-config, in this thread I also showed you that
your usage of config script is incorrect as:
1. AC_CHECK_TOOL should be use to check platform specific tools.
2. The config scripts must be prefixed with ${HOST}
3. The config scripts should have their own target directory, probably
outside of ${ROOT} as executing anything from ${ROOT} is incompatible
with cross-compile.

Let's summarize what I understand so far:

1. You should use the method of detecting and installing config
scripts to comply with autoconf patterns, this applies to the current
proprietary solution.

2. You did not answer the request of supporting both options of using
the gpgrt-config as default and allow people to use pkg-config if they
like, this will solve many of the problem other people are
experiencing and allow downstream maintainer to have predictable build
behavior if they so choose.

Thanks,
Alon

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
On Mon, 3 Dec 2018 00:31, alon.barlev@gmail.com said:

> Please explain again why not give an option for downstream to build
> gnupg components using pkg-config, this does not take anything from
> whoever wishes to continue to use current mode.

Because supporting two build systems is a PITA and costs us too much.

The changes Gniibe did to support pgk-config for users of our libraries
were already expensive enough and it is not justified to burn more money
with that. In particular because we and not you need to maintain such a
duplicated build systems.

After the next round of releases we can expect quite some extra work due
to these changes anyway. We will take this trouble and thus pretty
please stop complaining about that not being sufficient. There are much
more important things to do than to willy-nilly change an established
build system.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
On Tue, Dec 4, 2018 at 9:30 AM Werner Koch <wk@gnupg.org> wrote:
>
> On Mon, 3 Dec 2018 00:31, alon.barlev@gmail.com said:
>
> > Please explain again why not give an option for downstream to build
> > gnupg components using pkg-config, this does not take anything from
> > whoever wishes to continue to use current mode.
>

<snip>

> After the next round of releases we can expect quite some extra work due
> to these changes anyway. We will take this trouble and thus pretty
> please stop complaining about that not being sufficient. There are much
> more important things to do than to willy-nilly change an established
> build system.

Hello Werner,
Once again you ignore that even the current build system does not
comply with autoconf standards and should be fixed.
This was not required if you support pkg-config as we could have an
option, but if you insist not supporting pkg-config at least work to
fix the existing build to properly support multilib and cross compile.
Thanks,
Alon

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
Hello Alon.

Am Dienstag, den 04.12.2018, 22:54 +0200 schrieb Alon Bar-Lev:
> On Tue, Dec 4, 2018 at 9:30 AM Werner Koch <wk@gnupg.org> wrote:
> > On Mon, 3 Dec 2018 00:31, alon.barlev@gmail.com said:
> >
> > > Please explain again why not give an option for downstream to
> > > build
> > > gnupg components using pkg-config, this does not take anything
> > > from
> > > whoever wishes to continue to use current mode.

> <snip>

> > After the next round of releases we can expect quite some extra
> > work due
> > to these changes anyway. We will take this trouble and thus pretty
> > please stop complaining about that not being sufficient. There are
> > much
> > more important things to do than to willy-nilly change an
> > established
> > build system.

> Hello Werner,
> Once again you ignore that even the current build system does not
> comply with autoconf standards and should be fixed.
> This was not required if you support pkg-config as we could have an
> option, but if you insist not supporting pkg-config at least work to
> fix the existing build to properly support multilib and cross
> compile.

I don't see your problem at all. Most libraries for GPG, at least the
packages of Fedora, which I use, support pkg-config to link them, the
.pc files are available and usable. GPG itself is not a library so
there is no need for a .pc file.

I have no problem building the actual git snapshot of GPG only with the
installed libraries and header files from the system. So, what are you
complaining about? The .pc files which are not available in your case?
Write them, if you want to link the libs with pkg-config for
configuration.

There is really no need of changing the build system at all. And yes,
it is autoconf. The scripts are a little complicated to read, but it is
autoconf, for sure, with some "extras".

I, as a developer of software which uses GPG(me) and some of the
underlying libraries directly, have never had any real problem with the
actual build system.

Regards,
Dirk

PS: Thank you, Werner and the whole team, for your good work. And no
bugs, please. Pest patrol is really expensive. :D


--
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
Hello,

I think that I should explain from my viewpoint, not as an answer.

So, I'm writing this message for people who build GnuPG. As an
appendix, I will write an answer to reply, but that's not important
part.


Here we go.

In master branch, we did major improvement to introduce new method,
keeping old method. We are sorry to say that we don't accept further
change of old method. We keep old method unchanged (as bad as is).
Please use new method for new features.


(1) We introduce .pc files for GnuPG libraries (npth, libgpg-error,
libgcrypt, libassuan, libksba, and ntbtls) and for GPGME.


(2) We introduce new gpgrt-config script which is a portable script to
use .pc file for each ${HOST}. Since it supports all ${HOST} by a
single script, there will be no ${HOST}-gpgrt-config scripts, like
pkg-config (or <library-specific>-config) does in distribution
arrangement.


(3) We introduce new method which uses gpgrt-config script by updated
<library-specific>.m4. It's up to library users to prefer this m4 with
gpgrt-config, or to prefer pkg.m4 with pkg-config.

Still updated <library-specific>.m4 keeps old method of using
<library-specific>-config script (possibly wrong for some use cases, I
know), but we intentionally keep it for backward compatibility.


(4) For use of updated <library-specific>.m4 for new GnuPG libraries
which come with .pc files, since gpgrt-config script can be used, any
<library-specific>-config script (including
${HOST}-<library-specific>-config scripts) are not needed any more.
Obviously, for use of pkg.m4, <library-specific>-config script is no
need.

Distributions are suggested not to install <library-specific>-config, if
all software will be updated to use updated <library-specific>.m4, or
pkg.m4.

We keep distributing <library-specific>-config for a while, since old
<library-specific>.m4 can be supported.


(5) GnuPG build uses new <library-specific>.m4 with gpgrt-config. It
does require only a single gpgrt-config for all ${HOST}s for cross
build. No ${HOST}-gpgrt-config, no <library-specific>-config,
no ${HOST}-<library-specific>-config are required.

With .pc files which are handled by single gpgrt-config script, GnuPG
build has been improved, supporting many cross build cases (multiarch,
multilib in Arch/Fedora/OpenSUSE style, mingw for Windows).

No need of SYSROOT environment variable, no need of
--with-<library-specific>-prefix argument for configure, just run
simple configure with relevant --host=${HOST} (and --libdir for
multiarch).

Please test and enjoy new improvement, and please report problems
of new features.

* * *
An appendix:

Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> Regardless of using pkg-config, in this thread I also showed you that
> your usage of config script is incorrect as:
> 1. AC_CHECK_TOOL should be use to check platform specific tools.
> 2. The config scripts must be prefixed with ${HOST}

This claim is only valid to old code, not correct any more.

In new method, <library-specific>-config was gone, gpgrt-config is only
a single script which is portable, and we don't have
${HOST}-gpgrt-config script. So, AC_CHECK_PROG is enough.

> 3. The config scripts should have their own target directory, probably
> outside of ${ROOT} as executing anything from ${ROOT} is incompatible
> with cross-compile.

I think that you meant SYSROOT environment variable support. I know
it's a peculiar method (and possibly strange and wrong in some use
cases). It's only for specific cross build for Windows. We don't touch
this existing method. New users don't need to use this old method.

> 1. You should use the method of detecting and installing config
> scripts to comply with autoconf patterns, this applies to the current
> proprietary solution.

I understand your claim (and partly share your frustrations), which was
valid for old method.

It is somehow compilicated, but we also support old (in some cases,
wrong way) of detecting <library-specific>-config script, to support
existing build and existing software. We are conservative about that,
we don't have any idea to "fix" this part to comply "correct" autoconf
patterns.

And it is true that we still use gpgrt-config script for GnuPG build
(instead of pkg-config), but this is a single script with no ${HOST}
variants.

> 2. You did not answer the request of supporting both options of using
> the gpgrt-config as default and allow people to use pkg-config if they
> like, this will solve many of the problem other people are
> experiencing and allow downstream maintainer to have predictable build
> behavior if they so choose.

I have explained the reason why GnuPG build never use pkg-config for its
detection of GnuPG libraries. It's no need, no benefit, but comes with
possible risk.

Nevertheless, many of problems were solved in new method, just like
pkg-config can be achieved.

It's unfortunate, for some people, it hasn't achieved to the status of
complete victory (of using pkg-config for all) yet. Please don't
complain about that. As I suggested, when pkg-config will be evolved to
meet GnuPG build requirement, situation will be able to be improved.
Let's see, but, it's not now.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
On Tue, Dec 4, 2018 at 11:57 PM Dirk Gottschalk
<dirk.gottschalk1980@googlemail.com> wrote:
>
> Hello Alon.
>
> Am Dienstag, den 04.12.2018, 22:54 +0200 schrieb Alon Bar-Lev:
> > On Tue, Dec 4, 2018 at 9:30 AM Werner Koch <wk@gnupg.org> wrote:
> > > On Mon, 3 Dec 2018 00:31, alon.barlev@gmail.com said:
> > >
> > > > Please explain again why not give an option for downstream to
> > > > build
> > > > gnupg components using pkg-config, this does not take anything
> > > > from
> > > > whoever wishes to continue to use current mode.
>
> I have no problem building the actual git snapshot of GPG only with the
> installed libraries and header files from the system. So, what are you
> complaining about? The .pc files which are not available in your case?
> Write them, if you want to link the libs with pkg-config for
> configuration.
>
> There is really no need of changing the build system at all. And yes,
> it is autoconf. The scripts are a little complicated to read, but it is
> autoconf, for sure, with some "extras".

Just to make sure we are on the same page...
Have you tried cross compile a complete solution of libraries? Have
you tried cross-compile + multilib setup?
If you have, how many tweaks have you needed in order to make this work?

Thanks!
Alon

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH Libgpg-error] gpg-error.m4: support pkg-config [ In reply to ]
On 05/12/2018 12:35, Alon Bar-Lev wrote:
> If you have, how many tweaks have you needed in order to make this
> work?

It sounds like /you/ have tried it. If it's not too much work, can you
give an indication of the tweaks /you/ needed to build the current
master branch?

I know nothing of the subject at hand, but so far, from this
conversation I can distill that you think the build system should never
invoke anything in SYSROOT, whereas Werner thinks that is okay so long
as the things invoked are architecture-independent scripts such as a
Bash script.

And that you think GnuPG should follow best practices of various tools.

Furthermore, you are of the opinion it is trivial to do whereas Werner
uses the phrases "PITA" and "burning money".

However, the first two things are matters of differing points of view,
not directly things that actually mean something needs to be tweaked
before it actually works. And the difference of opinion on triviality
suggests you are not exactly talking about the same changes, or the
impact is misunderstood.

Finally, Gniibe seems to indicate that there are no tweaks needed at all
in all situations he considers in his mails. Which begs the question at
the top: which tweaks do you need to build current master succesfully?

Maybe my from-the-sideline observation can nudge the conversation into
more concrete matter? If not, feel free to disregard this.

Hoping that helps,

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

1 2  View All