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 <[email protected]> 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
