Christian Grothoff <groth...@gnunet.org> skribis: > On 06/03/2015 05:15 PM, Ludovic Courtès wrote: >> asg...@free.fr skribis: >> >>> This first week started with cleaning and organizing the draft >>> bindings I’ve been working on previously (set up of a proper directory >>> structure, a small Makefile, etc.), then most of the work has been on >>> mapping GnuNet’s data structures. >>> >>> This week, I’m heading for the remaining “most-needed” functions (URI >>> handling, scheduling) and some testing, and also writing a simplified >>> version of the `gnunet-search` utility, as it could be a good test and >>> example of usage for the bindings. >> >> OK, sounds like a good plan! >> >> Are you already using a public repo that we could look at? If not, we >> should set up a Git repository at gnunet.org or Savannah, whichever is >> more convenient. > > gnunet.org isn't quite setup for *public* Git's yet...
OK, I have requested the creation of a repo under the Guix project on Savannah: https://savannah.gnu.org/support/?108833 Rémi: I will add you on Savannah so you can push your code there when the repo is ready. Make sure to add a ‘COPYING’ for the GNU GPL v3, as well as copyright and license headers (see how this is done in Guix.) Feel free to contact me off-list for additional details. >>> Options handling: the standard way of writing software that uses >>> GnuNet’s API is to let GnuNet handle the command line options: the >>> API’s entry point, must be fed directly with the C arguments vector >>> `argv`; it assures that all GnuNet programs have a uniform CLI. The >>> first difficulty I encountred is: how to properly handle these >>> options? After some work, I decided to manually craft a fake `argv` as >>> a quick temporary fix. >> >> OK. Question for the GNUnet people: What’s the recommended way to >> handle argc/argv if we want to provide a library? > > Well, libgnunetutil contains a wrapper around getopt for our own > convenience, but I'm totally fine with using a language-specific > argv-parser for command-line tools. Note that GNUnet *libraries* > obviously also don't take command-line arguments, so I'm not sure what > the question is. > >> Typically a Guile >> module cannot be passed any arguments, and the initialization that >> happens is just that its top-level forms are evaluated when it’s loaded. >> Having to explicitly call an initialization function that takes an argv >> would look unidiomatic. > > Right, same applies for (most) GNUnet APIs, with the exception of our > "service" and "program" abstractions which are there to make it easy to > write a 'main' function. But I don't see a need to expose those two > APIs to Guile. OK, so I guess there’s nothing to worry about in the end. :-) Thanks for your feedback! Ludo’.
