View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004615 | GNUnet | other | public | 2016-08-10 23:24 | 2022-12-08 06:43 |
| Reporter | lynX | Assigned To | schanzen | ||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.19.0 | Fixed in Version | 0.19.0 | ||
| Summary | 0004615: How should a client application's autoconf check for the availability of GNUnet? | ||||
| Description | Here's the blurb of code that I inserted into configure.ac 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: #ifndef GNUNET_UTIL_LIB_H #define GNUNET_UTIL_LIB_H 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); const char* expect = "VFQCGVPZJJ6PHN5DQ6NWH1BJY3Q3SNF0BVCT2B1S4Q915SMYHDRW1X2BFTEEWXG9ZC23PVH3Y1W6D4DRKRTHV2CFGHAW66W52QGM0B8"; printf( "u2h(4404) = %s ... ", GNUNET_h2s( hash ) ); if (strcmp(expect, GNUNET_h2s_full( hash ))) return -1; return 0; } | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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 (!). |
|
|
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. |
|
|
> 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. |
|
|
I also find this platform.h quite strange. This is not a priority, I think. But couldnt we include platform.h by default and have a "define"-guard around it so that if developers want to bring their own platform.h it will NOT be included by us? That would be cleaner I guess. |
|
|
c0ab1e5de..de5949640 now includes a "gnunet_platform.h" which either includes the "platform.h" by gnunet or of GNUNET_CUSTOM_PLATFORM_H is defined with will include that. "gnunet_platform.h" is included by (most) gnunet subsystem/library headers automatically. |
|
|
Slight change: gnunet_platform.h and platform.h are now gone from include/. gnunet_util_lib.h should/can now be included most of the time. Including header which are in gnunet_util_lib.h will cause a readable error message telling you to include only gnunet_util_lib.h. Inclusion of dependencies of gnunet_util_lib.h should no longer be necessary, this is also reflected in gnunet-ext, gnunet-fuse and gnunet-gtk. tl;dr: Just include the header you need it should work. |
| 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 |
|
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 => |
| 2021-12-31 09:29 | schanzen | Target Version | 0.16.0 => 0.17.0 |
| 2021-12-31 09:32 | schanzen | Target Version | 0.17.0 => 1.0.0 |
| 2021-12-31 09:36 | schanzen | Target Version | 1.0.0 => 0.17.0 |
| 2022-06-04 23:13 | schanzen | Target Version | 0.17.0 => 0.18.0 |
| 2022-10-22 15:08 | schanzen | Assigned To | => Christian Grothoff |
| 2022-10-22 15:08 | schanzen | Status | confirmed => feedback |
| 2022-10-22 15:08 | schanzen | Note Added: 0019268 | |
| 2022-10-27 05:09 | schanzen | Target Version | 0.18.0 => 0.18.1 |
| 2022-12-01 10:36 | schanzen | Assigned To | Christian Grothoff => schanzen |
| 2022-12-01 10:36 | schanzen | Status | feedback => resolved |
| 2022-12-01 10:36 | schanzen | Resolution | open => fixed |
| 2022-12-01 10:36 | schanzen | Fixed in Version | => 0.18.2 |
| 2022-12-01 10:36 | schanzen | Note Added: 0019492 | |
| 2022-12-01 10:37 | schanzen | Target Version | 0.18.1 => 0.18.2 |
| 2022-12-05 11:20 | schanzen | Note Added: 0019497 | |
| 2022-12-05 11:23 | schanzen | Target Version | 0.18.2 => 0.19.0 |
| 2022-12-08 06:42 | schanzen | Fixed in Version | 0.18.2 => 0.19.0 |
| 2022-12-08 06:43 | schanzen | Status | resolved => closed |
