[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christian Grothoff
Subject: Re: gnunet-config and build informations (bug #5708)
Date: Sun, 25 Jul 2021 08:18:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

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

This works, because there is:

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

My 2 cents


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]
> [1] 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]