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

[Schanzenbach, Martin]

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.

BR

> On 25. Jul 2021, at 08:18, Christian Grothoff <grothoff@gnunet.org> 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:
> 
> 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
>> 
>

signature.asc
Description: Message signed with OpenPGP