Re: [GNUnet-developers] GSoC: Binary package distribution through GnuNet (report 1)

[ludo@gnu.org (Ludovic Courtès)]

Christian Grothoff <grothoff@gnunet.org> skribis:

> On 06/03/2015 05:15 PM, Ludovic Courtès wrote:
>> asgeir@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’.