View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005708||GNUnet||build process||public||2019-04-30 18:46||2019-07-07 21:26|
|Reporter||Florian Dold||Assigned To|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Product Version||Git master|
|Target Version||Fixed in Version|
|Summary||0005708: configure script should output summary of configuration, including libraries picked|
|Description||The configure script has lots of auto-detection. At the end, there should be a comprehensive summary of the build configuration.|
Having this would help with bugs like 0005707, since it would be immediately visible that *both* libgnurl and libcurl are enabled, which is bogus.
|Tags||No tags attached.|
||so basically extend what we have in the configure script already (at the end of it) and optionally output it to a file|
Yes. There is also another slightly related feature, that maybe it can be done in one go.
Many packages (I count 150 on my system) have a <pkgname>-config program, including curl and libgcrypt. The gnunet-config tool in GNUnet already does something else, but I've discussed with Christian that we could add flags to gnunet-config to print out the package configuration and basically serve a dual purpose.
So in addition to writing these values to a file, they should also be exposed via AC_DEFINE so that gnunet-config can output them.
It's useful both for other packages that consume GNUnet, as well as for figuring out what features your installed version supports. AFICT there is currently no other way than to look at the source tree and ./configure invocation for that. Some build systems (e.g. cmake and meson) can use this <pkgname>-config tool to discover dependencies.
I'm not sure writing to another _file_ makes sense, we have the configure output to the terminal, and of course options detected should go into gnunet_config.h via AC_DEFINE() -- many do already -- so that's already a file we generate with the result of configure. Expanding gnunet_config.h to include more is fine, having an extra file seems superfluous.
I'm not sure how this relates to gnunet-config (separate issue?), or why this was assigned to me (hence un-assigning).
||This already ends up in config.log, I don't understand why having another file is necesssary. If we want to extract it from there, we can just use an awk script to get the information out of there, given that we still have the source.|
||Having the gnunet-config tool handle this with say, --cflags, --ldflags etc in case you want to *install* this will be better because maybe (I'm not 100% sure) having a file which changes per installation might introduce non-reproducible artifacts to the distribution (not: the binary builds). Having gnunet-config handle this also means we can point to a single installed tool for developers and users.|
|2019-04-30 18:46||Florian Dold||New Issue|
|2019-04-30 18:46||Florian Dold||Status||new => assigned|
|2019-04-30 18:46||Florian Dold||Assigned To||=> Christian Grothoff|
|2019-04-30 18:46||Florian Dold||Relationship added||related to 0005707|
|2019-04-30 18:50||Florian Dold||Description Updated||View Revisions|
|2019-05-01 17:15||nikita||Note Added: 0014362|
|2019-05-01 18:55||Florian Dold||Note Added: 0014363|
|2019-05-02 14:32||Christian Grothoff||Note Added: 0014370|
|2019-05-02 14:32||Christian Grothoff||Assigned To||Christian Grothoff =>|
|2019-05-02 14:32||Christian Grothoff||Status||assigned => confirmed|
|2019-05-02 14:32||Christian Grothoff||Severity||minor => feature|
|2019-06-05 19:01||Christian Grothoff||Target Version||=> 0.11.6|
|2019-07-01 12:25||nikita||Note Added: 0014627|
|2019-07-01 12:30||nikita||Note Added: 0014628|
|2019-07-07 21:26||Christian Grothoff||Relationship added||related to 0005735|
|2019-07-07 21:26||Christian Grothoff||Product Version||=> Git master|
|2019-07-07 21:26||Christian Grothoff||Target Version||0.11.6 =>|