gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?


From: Christian Grothoff
Subject: Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?
Date: Sat, 9 Feb 2019 13:27:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 2/9/19 12:47 PM, Schanzenbach, Martin wrote:
>> - Gtk UI (already in separate repo) If we atomize gnunet.git as you
>> propose, either the gnunet-gtk configure.ac must increase
>> drastically in terms of complexity to test which of the
>> gnunet-atoms is available (welcome to 500 character configure
>> invocations) or we atomize this as well, which then means you can
>> write an novel for the installation-from-source handbook on the
>> dependency graph.
> 
> That should not be the case. Either GNUnet gtk+ is pluggable or it is
> a monolithic nightmare like GNUnet.git is now including a billion
> configure switches.
> 

Eh, did you even look at the code for which you are proposing to
restructure the build system? gnunet-gtk includes a common basis (lib/)
which is shared by all of the individual programs (conversation, fs,
identity, namestore, peerinfo, statistics, setup).  Each of the programs
is otherwise completely independent from the others.

The shared functionality in lib/ is tiny (2k LOC), the shared _build_
system itself is almost as large (600 LOC) and most certainly at least
as complex.

Splitting up the Git will also require us to replicate all of that build
logic.  A significant part of that effort will have to go into writing
proper M4 macros to avoid massive code duplication for testing for the
presence of gnunet-core and various gnunet-core features/versions/etc.

So gnunet-gtk is *neither* pluggable nor really monolithic, it is simply
a collection of binaries sharing a common base library.



Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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