| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
| |
gnunet_private_config.h insanity
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows third party programs to use gnunet either with the
platform header from the sources used to build to gnunet, or use their
own platform header by defining GNUNET_CUSTOM_PLATFORM_H which will be
included in its stead.
This also means that programs no longer must include "platform.h" (or
similar) manually.
The change (should be) backwards compatible to some degree.
Fixes #4615
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes two changes:
* Add a field to `struct GNUNET_OS_ProjectData' containing a URL (as a string)
pointing to the source code of the application.
* If the field is not NULL, add a handler for the REQUEST_AGPL messages
sending the specified URL to the client.
The handler is added both in client-service communications (i.e. local
services that don't make requests to other peers in the network) and in
peer-peer communications (CADET.) This way, any client (local or remote with
CADET) can request the source code location using a standardized mechanism
instead of writing ad-hoc solutions (unless the service/peer explicitly
specifies a NULL pointer.)
Signed-off-by: Christian Grothoff <christian@grothoff.org>
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, gettext doesn't work for out-of-tree applications. This is
because GNUnet forcibly set the text domain to "GNUnet" (which
apparently is also incorrect), so applications can't be localized unless
their localizations are distributed in-tree by GNUnet itself.
The attached patch tries to fix this by adding two more fields to
GNUNET_OS_ProjectData: one field is the gettext domain of the
application. As the documentation says, if it's NULL gettext is
disabled so that applications can use their preferred localization
method without having gettext interfering; the other field is
essentially the locale directory, so applications can specify a
different path if they want to, instead of having GNUnet infer it for
them.
Because some GNUnet libraries also use gettext internally (the util lib
is a prominent example), gettext has to be initialized before the
application takes over. I placed such initialization in
`GNUNET_OS_init' and `GNUNET_OS_project_data_get' because those are two
functions which are very likely to be called (especially the second one,
since it's used in `GNUNET_PROGRAM_run2'.) If there is a better place
(or some places where this is not enough) I can change it and resubmit
it for review.
I also changed gnunet-ext to keep it consitent with the patch. In
particular, it adds a header which is required for a successful
compilation, so you might want to at least make that change.
Thank you,
A.V.
P.S. I'm still not subscribed to the list... yet.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
routines
|
|
|
|
| |
GNUNET_SCHEDULER_TaskContext to all scheduler tasks; instead, allow the relatively few tasks that need it to obtain the context via GNUNET_SCHEDULER_get_task_context()
|
|
|
|
| |
--help
|
|
|
|
| |
with different libs, paths, binaries and environment variables
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
checking in windows. To do so, tested binaries must still be supplied
with valid commandline arguments, but on windows gnunet will utilize the
-d flag to run the programs initialization phase or privileged
operations only. In these modes, a program will not enter its mainloop
or communicate with the outside.
updated relevant function calls gnunet-wide to meet the extended
function parameters.
|
|
|
|
| |
updating code to run binaries from new location, which is no longer in PATH
|