Re: [GNUnet-developers] On applications using GNUnet

[Schanzenbach, Martin]

> On 5. Aug 2019, at 22:27, Alessio Vanni <address@hidden> wrote:
> 
> 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.

I do not see the benefit of adding unused includes to sources.

> 
>> 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.

If you build an out of tree service/app you need to follow the approach of
gnunet-ext or taler. Building it like that is inherently different from 
building it in
tree because you only have a limited API externally.

> 
> 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.

gnunet-ext (or other third party tools like taler I assume) use a configure
switch to tell your buildsystem where GNUnet is installed (e.g. --with-gnunet=).
It is perfectly reasonable to do it like that. The packager of the OS will know
the correct and expected values for the flag(s) so I do not see an issue here.

> 
> 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?)

You should not really have to worry about it as long as the DIRs (prefix, 
libexec, lib etc)
are correctly configured for your system.

> 
>> 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.

See Christians reply regarding how this is done for Taler. You most likely want
to follow their approach for the most part.

BR
Martin

> 
>> BR
>> Martin
> 
> Sincerely,
> A.V.
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers

signature.asc
Description: Message signed with OpenPGP