Re: gnunet-config and build informations (bug #5708)
Christian Grothoff writes: > With that change, the logic gnunet-config shared with taler-config and > anastasis-config is now properly moved into libgnunetconfig, so we can > avoid the PRELOAD hack in the future. > > For how to do GNUnet-only extensions of the existing gnunet-config tool, > please see the "backend_check" option. Hello, I checked it out and tried to bring the modified gnunet-config up to date with these changes. Following the 'backend_check' option implementation I can't seem to find any particular issue with the new flags, so hopefully I didn't miss anything important. Thanks, A.V.
Re: gnunet-config and build informations (bug #5708)
Hi Alessio, Sorry that it took me even longer to reply, but it took me a while to get around to coming up with a good answer. I've now done so with Git 00c03c7bb..f9f3cbe9f. With that change, the logic gnunet-config shared with taler-config and anastasis-config is now properly moved into libgnunetconfig, so we can avoid the PRELOAD hack in the future. For how to do GNUnet-only extensions of the existing gnunet-config tool, please see the "backend_check" option. I hope that answers this issue. Best, Christian On 8/3/21 4:49 PM, Alessio Vanni wrote: > Hello, > > apologies for the late reply... > > Christian Grothoff writes: > >> I suggest youy pass all of the information (also possibly via #define's) >> into the GNUNET_OS_ProjectData and grab it from there! That way, Taler >> can override it without having to change gnunet-config itself. > > I'm not really sure about this approach, but it's mostly because I don't > know the reasoning behind Taler's way of doing things. If I could get > somewhere resources about why Taler is overriding gnunet-config with > LD_PRELOAD, rather than using its own dedicated program, that would be > very helpful. > > At the very least, if the change is actually done in GNUnet, it would > help with coming up with a solution that would fit all the interested > parties (as much as possible), instead of something hacked together > without knowing anything. > > Also, I'm going to push a tentative Autoconf macro. It's going to be in > the same branch because it still relates to "build infos", but since it > lives in "contrib" it should not cause too many issues. > > Thanks, > A.V. > signature.asc Description: OpenPGP digital signature
Re: gnunet-config and build informations (bug #5708)
Hello, apologies for the late reply... Christian Grothoff writes: > I suggest youy pass all of the information (also possibly via #define's) > into the GNUNET_OS_ProjectData and grab it from there! That way, Taler > can override it without having to change gnunet-config itself. I'm not really sure about this approach, but it's mostly because I don't know the reasoning behind Taler's way of doing things. If I could get somewhere resources about why Taler is overriding gnunet-config with LD_PRELOAD, rather than using its own dedicated program, that would be very helpful. At the very least, if the change is actually done in GNUnet, it would help with coming up with a solution that would fit all the interested parties (as much as possible), instead of something hacked together without knowing anything. Also, I'm going to push a tentative Autoconf macro. It's going to be in the same branch because it still relates to "build infos", but since it lives in "contrib" it should not cause too many issues. Thanks, A.V.
Re: gnunet-config and build informations (bug #5708)
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 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
Re: gnunet-config and build informations (bug #5708)
On 25.07.21 15:23, Alessio Vanni wrote: > Hello, > > Christian Grothoff writes: > >> 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!) > > I don't follow Taler's development, so I didn't know about this "trick". > Thanks for reporting. Sure, it is very non-obvious ;-). > I'm going to push a patch to change the hardcoded values to something > based on the values returned by `GNUNET_OS_installation_get_path'. > Hopefully that's going to work for Taler, as I can't think of any other > way to have it print the includedir and the libdir otherwise :) I suggest youy pass all of the information (also possibly via #define's) into the GNUNET_OS_ProjectData and grab it from there! That way, Taler can override it without having to change gnunet-config itself. > As a side note, to keep gnunet-config coherent with the pkg-config > definition, I also had it print `-lgnunetutil' when using the `--libs' > flag. > > I don't know how Taler handles its public APIs, if it has any, so if an > application wants to compile against Taler it would be useful to have > taler-config also print e.g. `-ltalerutil'. Yes, it is similar. So you should get the "-gnunetutil" also from some new field you add to the GNUNET_OS_ProjectData. Ideally, you could even put an array of command-line options into GNUNET_OS_ProjectData, so that all of the new functions you add becomes fully customizable via LD_PRELOADs. > I doubt this is something that gnunet-config can handle internally, so > if Taler (or any application using the LD_PRELOAD + gnunet-config combo) > has special needs for the `--libs' (or even the `--cflags') flag, the > execution with that flag should be intercepted somehow and the > appropriate values appended to the default output of gnunet-config. My point was the "intercepted somehow" we should use is the customization via the GNUNET_OS_ProjectData! Happy hacking! Christian
Re: gnunet-config and build informations (bug #5708)
Hello, Christian Grothoff writes: > 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!) I don't follow Taler's development, so I didn't know about this "trick". Thanks for reporting. I'm going to push a patch to change the hardcoded values to something based on the values returned by `GNUNET_OS_installation_get_path'. Hopefully that's going to work for Taler, as I can't think of any other way to have it print the includedir and the libdir otherwise :) As a side note, to keep gnunet-config coherent with the pkg-config definition, I also had it print `-lgnunetutil' when using the `--libs' flag. I don't know how Taler handles its public APIs, if it has any, so if an application wants to compile against Taler it would be useful to have taler-config also print e.g. `-ltalerutil'. I doubt this is something that gnunet-config can handle internally, so if Taler (or any application using the LD_PRELOAD + gnunet-config combo) has special needs for the `--libs' (or even the `--cflags') flag, the execution with that flag should be intercepted somehow and the appropriate values appended to the default output of gnunet-config. Thanks, A.V.
Re: gnunet-config and build informations (bug #5708)
Hello, "Schanzenbach, Martin" writes: > But what the OP in the report also and possibly primarily thinks is missing > is a way to get the build information > which is output on configure at the end which is useful for users to > understand what kind of build configuration their gnunet installation is in. > E.g. the things listed at > https://git.gnunet.org/gnunet.git/tree/configure.ac#n2199 and following. > > Similar to, for example: > $ libgcrypt-config --algorithms > > I would assume something like > > $ gnunet-config --transports > or > $ gnunet-config --experimental > or > $ gnunet-config --http-client-backend > etc > > is what is expected. I see, it makes sense to also have those flags. I suppose that the `--transports' flag would print the content of the `transport_msg' variable (used by configure), maybe in the form of "Available transports: tcp udp...". Probably a `--database-backends' flag working similarly could also be useful. As for the other flags you listed, I'm not sure how to handle them. The `experimental' featureset doesn't have a clear list anywhere, so to find out what is considered experimental it's necessary to scan every Makefile.am and find out what is being guarded by the experimental definition and then hardcode the list in the appropriate place. It's not that great in my opinion, especially as when a feature is not experimental anymore the name has to also be removed from the hardcoded list printed by the flag. The `--http-client-backend' flag, and the others in the `etc.' part, I don't really know what should print at all. Is it something like enabled/disabled or should they print something else entirely? Thanks, A.V.
Re: gnunet-config and build informations (bug #5708)
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 >
Re: gnunet-config and build informations (bug #5708)
Hello Alessio, thanks for the work! I personally have never written an autoconf macro, but I would assume that it makes sense to have it. Regarding your patch: Lgtm, it addresses the first (basic) feature how I would expect it to happen. Which is allowing the caller to retrieve cflags or ldflags. This is what most *-config programs _also_ do and what our *.pc files should provide as well through pkg-config. But what the OP in the report also and possibly primarily thinks is missing is a way to get the build information which is output on configure at the end which is useful for users to understand what kind of build configuration their gnunet installation is in. E.g. the things listed at https://git.gnunet.org/gnunet.git/tree/configure.ac#n2199 and following. Similar to, for example: $ libgcrypt-config --algorithms I would assume something like $ gnunet-config --transports or $ gnunet-config --experimental or $ gnunet-config --http-client-backend etc is what is expected. So I think it makes sense to keep the bug open, but I think we can still get this in for 0.15.0. Thanks again and BR Martin On 24. Jul 2021, at 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
