[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] On applications using GNUnet

From: Alessio Vanni
Subject: Re: [GNUnet-developers] On applications using GNUnet
Date: Mon, 05 Aug 2019 22:27:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Hi Martin,

> 0. Is there a reason you include the new header into every single C file? 
> There does not seem to be
> a need for that in most cases.

It was mostly future-proofing.  While I was making changes I wasn't sure
if I were going to put some other things in there, so just in case I
added it in every file that is not a header.  It can also be used to
place anything GNUnet-specific that shouldn't go in platform.h, if
needed.  If it's too much it can be added only to files that strictly
require it though.  The point is to avoid placing those values (and any
that might be added in the future) out of installed headers.

> 1. If you want to build an application, even if it is "just" a CLI you need 
> to decide if
> you want to add it to the GNUnet tree or build it externally. As you said you 
> tried to
> build it externally first, but the PREFIX/lib location situation on gentoo 
> makes this difficult?
> If yes, we should try to address this problem first.
> You can specify the libdir and libexec using configure, e.g.:
> ./configure --libexecdir=/usr/lib64 --libdir=/usr/lib64

In theory, any 3rd party applications will always be built externally,
as the most common workflow is to install the library or framework in a
standard place, develop the application somewhere local (i.e. out of the
GNUnet tree in this case) and eventually distribute it so that other
people can install and use it.

To avoid misunderstanding: so far my experiments were in trying to
develop an out-of-tree application following that kind of workflow.  I
treated GNUnet as a framework to write applications that can connect to
a peer-to-peer network.  I don't know if this is the correct approach,
but it's certainly one of the possible ones.

The problem with the libexec directory isn't really about Gentoo, but
rather that it's not easy to find it.  On some systems it might be in
/usr/lib, on some others in /usr/lib64.  After giving it some thought, I
think the easiest approach is to add a notice about this in the
documentation, so that developers can act accordingly (e.g. by
specifying that configure must be called with a special flag or
something in the installation instructions.)  Another approach could be
to have GNUnet advertise the path to its libexec directory so that
configure can automatically pass it to the Makefile without having to
ask the user to specify it explicitly, but I don't know if it can be
done at all.

Anyway, this is only for services as they need to be discovered by ARM
when installed.  Writing a client poses no problems.

To be honest, it took me a while to understand how to get ARM to find my
test service.  The documentation doesn't really say anything about it
(or maybe I missed it?)

> 2. When 1. is fixed, the change/addition you made to getopt makes sense and 
> we should try to
> slim a patch/changeset down to just that.
> 3. If you still want to build your application in the tree, then the changes 
> to the gnunet
> help output in 1. and 2. are not necessary (as it will be GNUnet after all).
> Unless you choose to for in which case just replace/hardcode your
>  contact details. It would not make sense to report bugs of your fork to 
> GNUnet anyway.

The new getopt helper is meant to be used by the new "3rd party
application" library.  The "program" library that is used right now will
print a fixed message, which for the most part does not apply to
applications built out-of-tree.  The new helper uses informations taken
from a manifest defined by the application itself.  The whole
"application_lib vs program_lib" distinction was to keep a level of
backward compatibility, as I don't know how many 3rd party applications
have been written (and if they are still being used.)  Clients
distributed within GNUnet itself or that are part of the GNUnet project
can just use GNUNET_PROGRAM_run as the helpers used there work just fine
for them, but external applications need more customization thus
GNUNET_APPLICATION_run and the new getopt helper.

> BR
> Martin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]