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 >
