Mailing List Archive

pkg-config?
Hello,

I'd like to adopt pkg-config methodology to GnuPG. I mean,
providing PACKAGE.pc.

I know that we had discussions in the past.

Since then, situation has been changed; pkg-config 0.27 and later allow
--with-internal-glib option at configure time. We also have pkgconf
now. I think that our concern about dependency to another software is
smaller now.

So, I think that we can move now.


For GnuPG configure, we now have following:

gpg-error-config
ksba-config
libassuan-config
libgcrypt-config
npth-config
ntbtls-config

Using those *-config works, but I think that using pkg-config is better.
At least, using pkg-config which supports multiple libraries at once,
linking can be simplified and accurate.


Today, I have a specific problem.

These days, libgpg-error is used by many (ksba, assuan, gcrypt, ntbtls,
and GnuPG itself). Now, using each *-config, GnuPG's linking has
many -lgpg-error.

It is only redundant, for normal case, that's true.

But for a developer, who installs development version of libgpg-error in
/usr/local (and still keep using old libgpg-erro in system), he may
encounter a problem, say, if he still uses old ksba package.

That's because... while ksba-config --libs returns (for example)

-L/usr/lib/x86_64-linux-gnu -lksba -lgpg-error

new gpg-error-config --libs returns

-L/usr/local/lib -lgpg-error

Then, appending those to generate the executable kbxutil in gnugp/kbx,
old libgpg-error is selected, unfortunately.


I think that now is a good opportunity to move on.

Any thoughts?
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: pkg-config? [ In reply to ]
On Fri, 13 Jul 2018 07:22, gniibe@fsij.org said:

> Since then, situation has been changed; pkg-config 0.27 and later allow
> --with-internal-glib option at configure time. We also have pkgconf

Which is still a lot of code for a simple task.

> and GnuPG itself). Now, using each *-config, GnuPG's linking has
> many -lgpg-error.
>
> It is only redundant, for normal case, that's true.

Right (we could enhance the config scripts to remove the duplicates but
it would only be cosmetic).

> Then, appending those to generate the executable kbxutil in gnugp/kbx,
> old libgpg-error is selected, unfortunately.

The cumulative effect of -L and its correct ordering is both a problem
and a feature.

How is pgk-config supposed to solve this?

Of course we could do the original test linking stuff again to detect
this problem, but there ware may other build problems lingering when you
have several versions installed.


Shalom-Salam,

Werner

--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: pkg-config? [ In reply to ]
Hi,

On Friday, July 13, 2018 2:22:15 PM CEST NIIBE Yutaka wrote:
> I'd like to adopt pkg-config methodology to GnuPG. I mean,
> providing PACKAGE.pc.
>
> I know that we had discussions in the past.

Yes please. I had discussions with Werner about this some time ago and he
OK'ed it at least for libgpg-error, libassuan and gpgme as long as it would be
additional to the current -config scripts. The rationale was that we want to
make it easy for developers to find / link gpgme using standard tools.

The cmake find scripts for GnuPG libraries are complicated and uncommon because
they also support building natively "on Windows" against precompiled binaries
(which is something we support) and there the -config scripts don't work at
all. pkg-config files where the prefix variable can be changed would help with
that.

I just never got around to do it.

> Since then, situation has been changed; pkg-config 0.27 and later allow
> --with-internal-glib option at configure time. We also have pkgconf
> now. I think that our concern about dependency to another software is
> smaller now.
>
> So, I think that we can move now.

We are also using pkg-config to find other packages. So in my opinion it is
strange that we don't play nice with pgk-config.


Best Regards,
Andre

--
Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: pkg-config? [ In reply to ]
Hello, again,

This week, I struggle with shell programming. (I realized that what I
use was mostly bash features.)

NIIBE Yutaka <gniibe@fsij.org> wrote:
> I'd like to adopt pkg-config methodology to GnuPG. I mean,
> providing PACKAGE.pc.

I understand that adding requirement of pkg-config to the GnuPG build is
not good.

I think that it is good to provide *.pc file, for the users of
libraries, even if the GnuPG build process doesn't use pkg-config.

To be more concrete, how about using a shell script like the one
at the end of this mail, with config files which is shared
between the script and pkg-config users?


========================>8=>8=>8================== gpg-error.pc
prefix=/usr/local
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${prefix}/lib
host=x86_64-pc-linux-gnu

Name: gpg-error
Description: GPG Runtime
Version: 1.32-betaXXX
Cflags: -I${includedir}
Libs: -L${libdir} -lgpg-error
URL: https://www.gnupg.org/software/libgpg-error/index.html
========================>8=>8=>8==================

========================>8=>8=>8================== gpg-error-mt.pc
prefix=/usr/local
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${prefix}/lib
host=x86_64-pc-linux-gnu

Name: gpg-error
Description: GPG Runtime
Version: 1.32-betaXXX
Cflags: -I${includedir}
Libs: -L${libdir} -lgpg-error -pthread
URL: https://www.gnupg.org/software/libgpg-error/index.html
========================>8=>8=>8==================

Here is an example for gpg-error-config replacement:
========================>8=>8=>8==================
#! /bin/sh
#
# gpg-something-config, using a config file in pkg-config style, so
# that we can share such a config file between pkg-config
#

#
# get_var: get the variable value of NAME
#
# Variables are recorded in the shell variables named "VAR_<NAME>"
get_var () {
local name=$1

eval echo \$VAR_$name
}

#
# get_attr: get the attribute value of KEY
#
# Attributes are recorded in the shell variables named "ATTR_<KEY>"
get_attr () {
local name=$1

eval echo \$ATTR_$name
}

# Remove ${varname} part in the beginning of a string.
remove_var_expr () {
local varname=$1
shift

eval echo \"\${@#\\\$\\\{$varname\\\}}\"
}

# Given a string, substitute variables.
substitute_vars () {
local string="$1"
local line
local varname
local result

while [ -n "$string" ]; do
case "$string" in
\$\$*)
result="$result\$"
string="${string#\$\$}"
;;
\${*}*)
varname="${string#\$\{}"
varname="${varname%%\}*}"
result="$result$(get_var ${varname})"
string=$(remove_var_expr ${varname} ${string})
;;
*)
result="${result}$(printf %c "$string")"
string="${string#$(printf %c "$string")}"
;;
esac
done

echo "$result"
}

# Read a config file
read_config_file () {
local line
local varname
local value
local key

while read line; do
case "$line" in
*=*)
varname="${line%%=*}"
value="${line#*=}"
VAR_list="$VAR_list VAR_$varname"
read VAR_$varname <<EOF1
$(substitute_vars "$value")
EOF1
;;
*:\ *)
key="${line%%:\ *}"
value="${line#*:\ }"
ATTR_list="$ATTR_list ATTR_$key"
read ATTR_$key <<EOF2
$(substitute_vars "$value")
EOF2
;;
esac
done
}

usage () {
cat <<EOF
Usage: $1 [OPTIONS]
Options:
[--mt] (must be the first option)
[--prefix]
[--exec-prefix]
[--version]
[--libs]
[--cflags]
EOF
exit $2
}

if [ "$1" != "--mt" ]; then
CONFIG_FILE="gpg-error.pc"
else
CONFIG_FILE="gpg-error-mt.pc"
shift
fi

read_config_file < "$CONFIG_FILE"

while test $# -gt 0; do
case $1 in
--prefix)
output="$output $(get_var prefix)"
;;
--exec-prefix)
output="$output $(get_var exec_prefix)"
;;
--version)
echo "$(get_attr Version)"
exit 0
;;
--cflags)
output="$output $(get_attr Cflags)"
;;
--libs)
output="$output $(get_attr Libs)"
;;
--host)
echo "$(get_var host)"
exit 0
;;
*)
usage $0 1 1>&2
;;
esac
shift
done

# eval unset $VAR_list VAR_list
# eval unset $ATTR_list ATTR_list

echo $output
========================>8=>8=>8==================
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: pkg-config? [ In reply to ]
On Fri, Jul 20, 2018 at 04:22:19PM +0900, NIIBE Yutaka wrote:
>
> I understand that adding requirement of pkg-config to the GnuPG
> build is not good.
>
> I think that it is good to provide *.pc file, for the users of
> libraries, even if the GnuPG build process doesn't use pkg-config.

Sounds reasonable to me.

> To be more concrete, how about using a shell script like the one
> at the end of this mail, with config files which is shared
> between the script and pkg-config users?

This might also help me fix a recently discovered issue with the SWIG
builds similar to your own observations with multiple installations of
dev versions versus system versions.

Specifically that SWIG does not appear to be picking up alternative
dependencies passed to configure during the compiling of GPGME if
there are also versions of those dependencies in $PREFIX and/or
$EPREFIX. I'm still looking into where precisely that information
gets lost.


Regards,
Ben