Mailing List Archive

Hello,

Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> 1. Farfetched... can we support pkg-config? I can help to support this
> in parallel to the existing mechanism.

Thank you.

Somehow, we have started into this way (from libgpg-error). I put some
effort providing gpg-error.pc (as well as the gpg-error-config script)
in the master branch of libgpg-error. My plan is to extend it to other
libraries. Please have a look.

Please note that we need to keep the requirment of GnuPG build, as small
as possible. GnuPG build should not require pkg-config. This is
(still) important for older Unixen.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On Mon, Oct 8, 2018 at 3:40 AM NIIBE Yutaka <gniibe@fsij.org> wrote:
>
> Hello,
>
> Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> > 1. Farfetched... can we support pkg-config? I can help to support this
> > in parallel to the existing mechanism.
>
> Thank you.
>
> Somehow, we have started into this way (from libgpg-error). I put some
> effort providing gpg-error.pc (as well as the gpg-error-config script)
> in the master branch of libgpg-error. My plan is to extend it to other
> libraries. Please have a look.

OK, so while we are at this... the config script should also support
SYSROOT and output directories relevant to SYSROOT.
For example, when cross compling and acquiring CFLAGS or LDFLAGS
outputting -I/usr/include and -L/usr/lib will not allow to build.

Three tasks to help cross compile work:
1. *.m4: complete supporting SYSROOT to look for the *-config script
within that prefix.
2. *.m4: support both SYSROOT/bin and SYSROOT/usr/bin when looking for
*-config scripts.
3. *-config: add support of SYSROOT to output directories

> Please note that we need to keep the requirment of GnuPG build, as small
> as possible. GnuPG build should not require pkg-config. This is
> (still) important for older Unixen.

I do not think there is a problem to try pkg-config and fallback to
*-config in autoconf, and in any case provide pkg-config for consumers
that do not have this concern.

Thanks!

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On Sat, 6 Oct 2018 11:07, alon.barlev@gmail.com said:

> 3. Specify SYSROOT as global --with-xxx-prefix.

I actually liked that and iirc implemented it for one or two packages.

> 1. Farfetched... can we support pkg-config? I can help to support this
> in parallel to the existing mechanism.

Gniibe alreadt started with this but pkg-config will only be the second
choice.

> 2. Can you please add SYSROOT support for all dependencies? (npth, ksba, assuan)

Yes. Makes a lot of sense and avoid surprises.

> 3. Can you please search in both SYSROOT/bin and SYSROOT/usr/bin for
> config script?

Yes.

Would you be so kind and open a feature request?


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On Mon, Oct 8, 2018 at 4:59 PM Werner Koch <wk@gnupg.org> wrote:
>
> On Sat, 6 Oct 2018 11:07, alon.barlev@gmail.com said:
>
> > 3. Specify SYSROOT as global --with-xxx-prefix.
>
> I actually liked that and iirc implemented it for one or two packages.
>
> > 1. Farfetched... can we support pkg-config? I can help to support this
> > in parallel to the existing mechanism.
>
> Gniibe alreadt started with this but pkg-config will only be the second
> choice.
>
> > 2. Can you please add SYSROOT support for all dependencies? (npth, ksba, assuan)
>
> Yes. Makes a lot of sense and avoid surprises.
>
> > 3. Can you please search in both SYSROOT/bin and SYSROOT/usr/bin for
> > config script?
>
> Yes.
>
> Would you be so kind and open a feature request?

Hi,

I was about to do that, but first checked out the master of
libgpg-error and found out that you already support pkg-config and
converted the config script to delegate calls to the pkg-config. There
are some gaps that can be solved. Then the same can be replicated to
all other projects.

I created a patch[1] with the required fixes, can you please review? I
added some comments to describe reasoning. Most of the changes in the
gpg-error.m4 are indent changes, please ignore them.

The logic is simple, if a prefix was not provided explicitly and the
config script was not provided explicitly, try autodetection using
pkg-config before fallback of config script detection.

I checked this briefly and it works for native, multilib and cross compile.

Regards,
Alon

[1] https://github.com/alonbl/libgpg-error/pull/1/files

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hello,

Thanks for yor try. Please have a lock at gnupg/doc/HACKING [0],
and submit your change to dev.gnupg.org or this maling list.
Before your submission, I'd suggest to minimize your change
(e.g. don't include indentation change).

Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> libgpg-error and found out that you already support pkg-config and
> converted the config script to delegate calls to the pkg-config.

No, the config script (gpg-error-config) never delegates to pkg-config.
It *does* handle the gpg-error.pc file by itself.

We share the gpg-error.pc file between gpg-error-config and pkg-config,
and I'd like to keep deviation by gpg-error-config as small as possible.


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


> There are some gaps that can be solved. Then the same can be
> replicated to all other projects.

Today, I push two changes:

gpg-error-config: Fix the place of *.pc (for multilib).
9f71b28dcb38e1d5d9001692e2f64009396aaf9b

gpg-error-config: Add PKG_CONFIG_SYSROOT_DIR support.
6167f3c461a4e53ccc5af620cdbfa28bfa9234f5

The first one is what you pointed out.
The second one is supporting cross build.


[0] https://dev.gnupg.org/source/gnupg/browse/master/doc/HACKING
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

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

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

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

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

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

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

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

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

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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On Wed, Oct 10, 2018 at 7:51 AM Alon Bar-Lev <alon.barlev@gmail.com> wrote:
>
> On Wed, Oct 10, 2018 at 5:18 AM NIIBE Yutaka <gniibe@fsij.org> wrote:
> >
> > Hello,
> >
> > Thanks for yor try. Please have a lock at gnupg/doc/HACKING [0],
> > and submit your change to dev.gnupg.org or this maling list.
> > Before your submission, I'd suggest to minimize your change
> > (e.g. don't include indentation change).
> >
> > Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> > > libgpg-error and found out that you already support pkg-config and
> > > converted the config script to delegate calls to the pkg-config.
> >
> > No, the config script (gpg-error-config) never delegates to pkg-config.
> > It *does* handle the gpg-error.pc file by itself.
> > We share the gpg-error.pc file between gpg-error-config and pkg-config,
> > and I'd like to keep deviation by gpg-error-config as small as possible.
>
> Yes, I should have phrased it better, it is great you begin support
> other libraries to use pkg-config, this is a great change in spirit.
>
> > Well, I repeat: GnuPG build process never depends on pkg-config.
>
> This is not entirely true you do have projects that use pkg-config,
> just not via the pkg.m4 macro for some reason.
> Providing pkg-config fixes issues for all packages outside of the
> gnupg project - that's great.
> However, the entire problem is that the gnupg project packages
> continue to use these proprietary config script and try to search for
> them during build, this tends to break, for example:
> 1. configure script cannot find these in path when building cross
> compile, autoconf shoud be modified to explicitly look for these at
> SYSROOT/bin:SYSROOT/usr/bin
> 2. multilib cannot use a single script, you need to install these
> scripts as HOST-xxx-config and use AC_PATH_TOOL instead of
> AC_PATH_RPOG
>
> However, using pkg-config do not have these issues, so using it
> enables you to bypass these issues without fixing them.
> I provided a clean way to use pkg-config if available and if not
> fallback to current proprietary mechanism, it takes nothing from the
> existing process, if user do not explicitly ask for config script and
> pkg-config is not available on system the current process remains.
>
> Will you feel better if we have --enable-pkg-config in autoconf
> disabled by default, and can be enabled by downstream that support
> pkg-config?
> Logic: --enable-pkg-config - use pkg-config instead of proprietary
> mechanism, this is as simple as and for sure do not take anything from
> anyone if not explicitly enabled:
>
> if test x"${enable_pkg_config}" = xyes; then
> PKG_CHECK_MODULES([GPG_ERROR], [gpg-error >=
> $min_gpg_error_version], , [enable_pkg_config=no])
> PKG_CHECK_VAR([GPG_ERROR_MT_CFLAGS], [gpg-error], [mtcflags])
> PKG_CHECK_VAR([GPG_ERROR_MT_LIBS], [gpg-error], [mtlibs])
> fi
> if test x"${enable_pkg_config}" = xno; then
> # current code
> fi

Patch is available[1].

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

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


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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel