[Top][All Lists]

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

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

From: Schanzenbach, Martin
Subject: Re: gnunet-config and build informations (bug #5708)
Date: Sun, 25 Jul 2021 17:45:32 +0000

IDK this does not sound like a good feature to me.
I understand that it is possible, but it does not really make sense.

Any application/project using gnunet(util) should provide its own *-config.
Having gnunet-config be able to dynamically load different configurations is 
asking for trouble.

I would rather have taler provide its own binary and functionality. After all, 
it does have its own sources.
It also may have its own requirements for the -config tool at which point not 
only do we possibly have a very oddly behaving gnunet-config
as it depends on the LD_PRELOAD, but taler also cannot really add 
taler-specific flags to it.


> On 25. Jul 2021, at 08:18, Christian Grothoff <> wrote:
> 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:
> 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
> 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]
>> [1] 

Attachment: signature.asc
Description: Message signed with OpenPGP

reply via email to

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