Been somewhat slow day ... the four entries mentioned in last blog post are things that have been delayed and delayed and delayed for ages, because of some problems regarding them, so now I'm trying to figure out possible solutions.

First, we have the build system ... I think the best approach here is to go with recursive configure; each module has it's own configure script, so they can be built outside the main source tree aswell as in the source tree. For compiling modules in, naturally the module must be built within the main source tree.

While we'r at it, perhaps it's time to finally separate the base library, and the p2p-related code. Namely, hydranode includes a set of generic classes / cross-platform wrappers (networking, range management, config, logging etc), which are truly generic and are useful in any context, not just hydranode. I'v kept the code separate, but never actually got around to perform the physical separation.

So, the end result should be like this:
a) Base library, called libhydranode (or smth similar), which includes cross-platform API plus a general-purpose class library. This also includes our current MD4, MD5 and SHA1 transformers ... will later be replaced with Botan library calls instead.
b) HydraNode executable; includes FilesList, SharedFile, PartData, MetaDb and so on and so forth - e.g. everything else. Links against libhydranode (either dynamically, or builtin - static linkage + modules will probably cause problems).
c) Modules; each module has it's own configure script; modules require libhydranode and HydraNode headers for compilation; modules can also require headers from other modules for compilation, in which case we'r dealing with inter-module dependancies. This is still somewhat a grey area - if we leave the required-modules loading to the host OS, we have some problems regarding module initialization - we can't call the init functions well ourselves ... tho I think there's smth like _init() or like that that the OS calls on module init ....

With make install, we would install libhydranode headers into usr/include/hn, hydranode executable headers into same place (no overlapping files ... tho maybe it's better to still separate them?) ... modules would naturally go to /lib/hydranode/ (would love to put them into /lib/modules/hn, but I think /lib/modules is dedicated to kernel-modules only?) ...

Any other ideas regarding compilation/installation/etc topics?

Note: All of this only affects POSIX platforms, win32 is completely different topic - for win32, we have to release a separate HydraNode DevKit, which includes all the neccesery .lib files and headers - that's a completely different topic.

Madcat, ZzZz