[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] GSoC: Binary package distribution through GnuNet
From: |
Ludovic Courtès |
Subject: |
Re: [GNUnet-developers] GSoC: Binary package distribution through GnuNet (report 1) |
Date: |
Fri, 05 Jun 2015 09:39:21 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Christian Grothoff <address@hidden> skribis:
> On 06/03/2015 05:15 PM, Ludovic Courtès wrote:
>> address@hidden 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’.