Hello, Thanks for your explanation. I learn.
Let me explain from GnuPG development side. We care traditional UNIXen and unusual OSes. (minimum version of) GnuPG should be able to be built and installed in early stage of development. Simon McVittie <s...@debian.org> wrote: > Control: tags -1 - wontfix OK. > That will fix cross-compilation if dependent packages are changed to > use (for example) PKG_CHECK_MODULES([GPG_ERROR], [gpg-error >= 1.33]) > instead of AM_PATH_GPG_ERROR([1.33]). Yup. That is my intention. But... please note that, we don't have an idea doing like that for GnuPG and its friends. For building GnuPG, pkg-config (or its alternatives) should not be one of requirements. > Is > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=src/gpg-error-config-new.in > the new script? Yes. > It's very unusual to parse .pc files "by hand" like this. I know. Someone has to do unusual thing to break a tie. I don't think it's a good solution, but it makes sense in this situation. Ugly compromise, but I did my best to provide gpg-error.pc from upstream. > The usual way to consume .pc files is to run pkg-config (the reference > implementation in C) or pkgconf (a reimplementation in Perl). Perhaps, you mean PkgConfig. It seems it lacks PKG_CONFIG_SYSROOT_DIR support. There is another alternative, pkgconf in FreeBSD. This looks easier to build. > For Debian, I wonder whether we might be able to patch the script to > remove this part, which looks like the only architecture variation: > > prefix=@prefix@ > exec_prefix=@exec_prefix@ > libdir=${PKG_CONFIG_LIBDIR:-@libdir@} > PKG_CONFIG_PATH="$PKG_CONFIG_PATH${PKG_CONFIG_PATH:+:}${libdir}/pkgconfig" For Debian, where we can assume good environment, package maintainer(s) can do many things. I'd suggest something like: (1) Having architecture independent -dev package _and_ architecture dependent -dev package, (2) by installing original gpg-error-config as <triplet>-gpg-error-config, (3) ... and installing Debian specific gpg-error-config which detects architecture dependent path dynamically. Just an idea. I don't know this feasibility. > This is not usually possible. If I run gpg-error-config, for example like > this: > > https://sources.debian.org/src/deja-dup/38.0-1/meson.build/?hl=60#L60 > > how do you know which architecture I wanted? Should libdir have the triplet in multiarch environment? Or simply invoking 'dpkg-architecture -qDEB_HOST_GNU_TYPE'? * * * These posts from me are basically to inform forthcoming upstream changes. I don't insist changes for Debian packaging. It's up to Debian. On the other hand, we are welcom to improve libgpg-error to be Debian friendly (but not Debian specific). --
