Given that we don't install a HOST-gpg-error-config tool, it does not make sense
to look for it.

AC_PATH_TOOL will fall back to gpg-error-config, so the default behavior is
unchanged. AC_PATH_PROG however will wrongly select the host's gpg-error-config
which breaks cross-compiling. it isnt up to random packages to manage the HOST
prefixed tools, so the gpg-error package not explicitly installing it is
irrelevant. cross-build systems take care of creating the wrappers automatically.

I don't agree. Your program might install HOST-prefixed tools, our programs
don't thus I can't see that as a but. You need to pass the correct
--with-gpg-error-prefix option. The GnuPG related software does this for 10
years or so.

It might indeed be useful to install such HOST prefixes wrappers for the config
scripts; but until know I have not seen any request for it. Replacing it by
AC_PATH_TOOL is no sulution because AM_PATH_GPG_ERROR does more than looking for
the config script.

i'm not requesting you install HOST prefixed wrappers. that would actually be
worse since people setting up cross-compile environments already generically
take care of this issue.

the fact that AM_PATH_GPG_ERROR "does more" is irrelevant ... what it does would
work exactly the same regardless of the name of the config script. so
AC_PATH_TOOL is a solution because it adds more programs to the search path
before falling back to the canonical gpg-error-config.

you might be OK with forcing everyone to manually figure out and pass the
appropriate configure options to simply find a config script, but it makes
absolutely no sense to me. my proposal doesnt change the default behavior
(which you seem to be keen on keeping), but it additionally makes things sanely
"just work" in a cross-compile environment where the tools lacking a HOST prefix
almost always are the wrong ones to use.

another option would be to punt all of this custom config-script usage and use
standard pkg-config files. since pkg-config is doing things the right way from
the ground up, it's hard for packages installing a .pc file to actively screw
things up.

The idea for a search path for a cross-build environment is not sane. If you
have a cross-build environment then it is easy to set it up correclty. If your
environment is already broken, gcrypt-config could only help by printing an
additional warning, but it will never be bulletproof.

pkg-config is entirely broken when it comes to cross-building. Sorry. We had
enough trouble with it to the end that we had to write a wrapper for it in the
gpg4win project.

Okay, using AC_PATH_TOOL to implement AM_PATH_GPG_ERROR makes sense.
I changed libgpg-error and updated the macro in libgcrypt master.

I also add a new config option --host to print a warning if the used
config script was not built for the current host. This might give
sporadic warnings if host triplets are not 100 identical, but better a
warning than a failure which is not easy to track down.

Thanks, for the suggestion.

i dont quite understand/agree with the last few comments, but i guess it doesnt
matter that much since the code now uses AC_PATH_TOOL which is all i wanted ;)

thanks !