Alo Sarv
lead developer

Donate via
MoneyBookers

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary
irc.hydranode.com/#hydranode

Sunday, March 27, 2005

Thoughts/ideas on build/install system upgrades

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



Comments:
You might be interested to know (or not ;-) that hydranode compiles and runs fine on my athlon64 system in 64 bit mode.

It did crash a couple of times. The first was when it tried to hash a 0 byte file. After that it ran about 8 hours and crapped out.
 
a single package would make it easier to package and install from source
 
http://www.pathname.com/fhs/pub/fhs-2.3.html
 
http://www.pathname.com/fhs/pub/fhs-2.3.html
 
In my opinion we should install hydranode to /opt/hydranode...
 
Precompiled headers please! Helps build times a lot.
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?