Re: gnunet-config and build informations (bug #5708)

[Christian Grothoff]

hi Alessio,

Two points:
- good autoconf macro would indeed be appreciated
- gnunet-config patch looks good, except for some funky requirement:

GNU Taler has taler-config, which recycles gnunet-config in a funky way
using LD_PRELOAD:

https://git.taler.net/exchange.git/tree/src/util/taler-config.in

This works, because there is:
https://git.taler.net/exchange.git/tree/src/util/os_installation.c

which overrides gnunet-config settings to turn it into taler-config!

So _ideally_, we would use the GNUNET_OS_ProjectData instead of directly
using hard-coded values for the output of the new flags. That way, we
could modify GNU Taler so that taler-config will not return the GNUnet
flags, but the Taler flags (again using preload, without copying the
source!)

My 2 cents

Christian

On 24.07.21 22:51, Alessio Vanni wrote:
> Hello,
> 
> I made an attempt at implementing what was discussed in bug #5708 [0],
> that is, additional flags for `gnunet-config' to print various
> informations similar to what other `*-config' tools do
> (e.g. `nss-config'.)
> 
> After sending this mail I'm going to push a branch called
> 'dev/vanni/build-info'; it's a separate branch because even though the
> changes are very simple (even including the documentation), I'd like to
> get some feedback first, especially if more flags are requested.
> 
> The following is a bit off-topic, but since it's something that might
> leverage the new gnunet-config flags, I'm going to ask here regardless.
> 
> Would it be possible to provide with the core GNUnet installation an
> Autoconf macro to detect GNUnet properly?  I'm using Autoconf to manage
> the GNUnet-based applications I'm writing, but detecting GNUnet is a bit
> of a mess.
> 
> Of course with the new gnunet-config I can just rely on it, but if I had
> a macro provided by GNUnet itself, much like other programs like for
> example Guile Scheme do [1], it'd be better.
> 
> This is especially true as getting a third-party GNUnet-based
> application to compile has surprising caveats: a very noticeable one is
> that, apparently, the `netinet/in.h' header is required when neither
> `gnunet_config.h' nor `platform.h' are `#include'd (which is what
> happens with third-party applications, at least those built using
> Autoconf.)
> 
> This is something that can be noticed only when the program is actually
> compiled, but with a GNUnet-specific macro the check for the necessary
> headers (and all that it entails) can be done implicitly by the macro
> itself.
> 
> I've made an attempt locally which first uses pkg-config and then falls
> back to the new gnunet-config, but before pushing it to the remote
> repository I'd like, once again, to hear some feedback on the matter, be
> it to pay attention to certain configurations or even be just a matter
> of following certain conventions.
> 
> Thank you,
> A.V.
> 
> ---
> 
> [0] https://bugs.gnunet.org/view.php?id=5708
> [1] 
> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=meta/guile.m4;h=48642f027f7b002d40658511fe3bb831e83ebdfc;hb=HEAD
>