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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
