[Top][All Lists]

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

Re: [Taler] Build process for wallets

From: Oliver Broome
Subject: Re: [Taler] Build process for wallets
Date: Sat, 30 May 2015 18:48:33 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0


Am 30/05/2015 um 09:51 schrieb Christian Grothoff:
> Hi!
> Based on our telco last night, I revamped our build process(es) to make
> it easier to build Taler wallets with minimal dependencies (i.e. no GNU
> libextractor, no libltdl, no libz, etc.).
First off, thanks for doing this! Much appreciated.
> So here is how to use the new system:
> 1) To compile the Taler mint, proceed as before
>     (the mint does require libltdl, and we don't care about minimizing
> dependencies there so much)
> 2) To compile Taler wallets, you must now:
> a) compile GNUnet with "--enable-taler-wallet" given to configure; this
> will the NOT compile 99% of GNUnet and only
>     generate a libgnunetutil_taler_wallet with about 1/3 of the code
> from libgnunetutil
>     Note that this library is NOT generated at all without this option.
> Also note that you thus MUST compile GNUnet twice
>     if you want to compile both mint and wallets.
> b) compile taler-mint (!) with "--enable-wallet", this will then not
> compile 95% of taler-wallet and only
>     generate a libtalerutil_wallet that depends on
> libgnunetutil_taler_wallet
> c) compile your wallet and link it against libgnunetutil_taler_wallet
> Right now, the result still depends on libunistring (via GNUnet's
> 'strings.c'), but that could be easily removed in the future if we
> decide we don't need the respective routines.
libunistring seems to compile without any issues, so that shouldn't be a
problem for now - at least for me and my Android development.
However, when compiling GNUnet in it's current state, it still depends
on libextractor:

    make[4]: Leaving directory 
    Making all in util
    make[4]: Entering directory 
      CC     common_allocation.lo
    In file included from ../../src/include/gnunet_crypto_lib.h:56:0,
                     from ../../src/include/gnunet_util_lib.h:39,
                     from common_allocation.c:27:
    ../../src/include/gnunet_common.h:1125:0: warning: "__func__" redefined 
[enabled by default]
     #define __func__ __FUNCTION__
    In file included from 
                     from ../../src/include/platform.h:48,
                     from common_allocation.c:26:
 note: this is the location of the previous definition
     #define __func__ __PRETTY_FUNCTION__
    In file included from ../../src/include/gnunet_bio_lib.h:32:0,
                     from ../../src/include/gnunet_util_lib.h:41,
                     from common_allocation.c:27:
    ../../src/include/gnunet_container_lib.h:38:23: fatal error: extractor.h: 
No such file or directory
     #include <extractor.h>
    compilation terminated.
    Makefile:2012: recipe for target 'common_allocation.lo' failed
    make[4]: *** [common_allocation.lo] Error 1
    make[4]: Leaving directory 

Now, I'm still not entirely familiar with all the interdependencies, so
I'm not sure if this will be an entirely qualified remark. Please bear
with me.

As far as I can tell, common_allocation.c is necessary because GNUnet
handles its own memory allocation and then, by extension, the Taler
wallet's as well. So that obviously cannot be removed. I am not entirely
sure about I/O-related code, though. Personally speaking, it would
probably be more comfortable and portable if this could be handled by
the wallets themselves, using APIs provided by the OS/Platform/whatever.

Barring any incompetence on my behalf, I see two things that require
further inspection:
 - common_allocation.c and others include gnunet_util_lib.h instead of 
gnunet_util_taler_wallet_lib.h, which seems to have been included for
wallet purposes
 - both gnunet_util_lib.h and  gnunet_util_taler_wallet_lib.h include
references to gnunet_container_lib.h, which in turn includes extractor.h
- this is something I would like to avoid due to the breakage shown
above and the fact that the Taler wallets probably won't need to be able
to extract metadata from files.

What say you, Christian?
> Happy hacking!
> Christian

reply via email to

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