> On 5. Aug 2019, at 22:27, Alessio Vanni <[email protected]> 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
