View Issue Details

IDProjectCategoryView StatusLast Update
0004615GNUnetotherpublic2021-06-15 13:37
ReporterlynX Assigned To 
Status confirmedResolutionopen 
Product VersionGit master 
Target Version0.16.0 
Summary0004615: How should a client application's autoconf check for the availability of GNUnet?
DescriptionHere's the blurb of code that I inserted into of the psyclpc driver in order to detect if GNUnet is installed, libgnunetcadet is available and the crypto is sane.

It isn't ideal because it uses the deprecated GC_u2h() function, but everything else in cadet_api.c looked less suitable for a quick test to me.

The other impractical thing is the terrible number of necessary includes which even need to be in that order to not break and produce odd error messages. This is not exactly spectacularly good developer UX. Looks like some header files are missing the classic multiple-include protection construct:


And I really didn't understand why, in the role of a developer writing some code against GNUnet, I should have to manually include platform.h which doesn't even conform to the naming standards. My "developer expectation" was that I should only need #include <gnunet/gnunet_cadet_service.h> and that would fetch all the essential dependencies by itself, this way also reducing the chances that my code will break with some later gnunet version. Is there any higher reasoning for this behavior, or should I just go ahead and streamline those header file dependencies?

Actually my "developer/user expectation" would be that #include <gnunet/cadet.h> should be the thing. Even "service" is an implementation detail that could change in future.
Additional Information#include <gnunet/platform.h>
#include <gnunet/gnunet_crypto_lib.h>
#include <gnunet/gnunet_common.h>
#include <gnunet/gnunet_util_lib.h>
#include <gnunet/gnunet_cadet_service.h>

int main(void) {
    const struct GNUNET_HashCode *hash = GC_u2h (4404);
    printf( "u2h(4404) = %s ... ", GNUNET_h2s( hash ) );
    if (strcmp(expect, GNUNET_h2s_full( hash ))) return -1;
    return 0;
TagsNo tags attached.


Christian Grothoff

2016-08-17 00:36

manager   ~0011032

The problem is that 'platform.h' depends on gnunet_config.h so that it can #include the right system headers. Given the different platforms we have (W32, OSX, Solaris, GNU) it is _impossible_ to do this in a portable way without reliance on a configure-generated config.h.

However, we're not supposed to #include 'gnunet_config.h' as that's not a stable header. So the 'platform.h' provides a _convenience_ way around it by defining the platform-specific headers, which you do not have to use if your project has its own way of detecting and #including platform-specific details.

So I'd love to clean this up, but am not aware of a fix that would then still allow the code to build on the various target platforms. Not to mention testing any change there on 4-6 platforms isn't my definition of good fun.

Christian Grothoff

2016-08-17 00:37

manager   ~0011033

Last edited: 2016-08-17 00:40

Oh, and in the above

#include <gnunet/gnunet_crypto_lib.h>
#include <gnunet/gnunet_common.h>
#include <gnunet/gnunet_util_lib.h>

are definitively not required.
You should only ever need platform + subsystem, and please note that some projects that use GNUnet don't use the GNUnet-platform header their, but their own (!).

Christian Grothoff

2016-08-17 00:38

manager   ~0011034

Oh, and using GC_u2h is a terrible idea, as it will disappear very soon. It was introduced as a short-term hack, and it will die before the next release.


2016-08-17 11:20

developer   ~0011037

> So I'd love to clean this up, but am not aware of a fix that would then still allow the code to build on the various target platforms.

Actually it is very simple. You can make gnunet_cadet_service.h also include platform.h or make a cadet.h which contains these two lines:

#include <gnunet/platform.h>
#include <gnunet/gnunet_cadet_service.h>

It is no drama that some files are generated on installation, but it is unwise if applications needlessly contain specific things that may go away in future versions, no?

> Oh, and using GC_u2h is a terrible idea

That's why I opened up this report. I don't see a better option.

Issue History

Date Modified Username Field Change
2016-08-10 23:24 lynX New Issue
2016-08-17 00:36 Christian Grothoff Note Added: 0011032
2016-08-17 00:37 Christian Grothoff Note Added: 0011033
2016-08-17 00:38 Christian Grothoff Note Added: 0011034
2016-08-17 00:40 Christian Grothoff Note Edited: 0011033
2016-08-17 11:20 lynX Note Added: 0011037
2019-07-11 12:14 user1415 File Added: 123.pdf
2019-07-11 12:42 schanzen File Deleted: 123.pdf
2020-10-29 11:31 schanzen Assigned To => schanzen
2020-10-29 11:31 schanzen Status new => confirmed
2020-10-29 11:31 schanzen Target Version => 0.15.0
2021-06-10 19:36 schanzen Target Version 0.15.0 => 0.16.0
2021-06-15 13:37 schanzen Assigned To schanzen =>