Alo Sarv
lead developer

Donate via

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

Saturday, July 16, 2005

New build system (continued)

Since until now, we'v only used MSVC on win32 to compile hydranode, some additional delays were introduced due to mingw-specific issues.

First of all, linking with boost_program_options library failed due to some odd reasons; even boost regression tests are failing in the case (and have been failing for a year already apparently), namely in dll configuration - static linkage works fine, but that's not an option for us. The developers have said it fails "due to unresearched issues". Anyway, I did some research, and found that we need -Wl,--enable-runtime-pseudo-reloc linker flag to fix it. An email to the library author is on it's way.

Other issue that seems to come up is related to paths handling (using boost_filesystem library). For some reason, boost::filesystem::path outputs proper win32 paths (e.g. \ as separator), but refuses such paths as input, when compiled with mingw. This issue still needs some research.

On Linux, it builds properly (hncore and hnbase library), but running directly from source tree isn't possible yet, since linux doesn't search for libraries in current dir (I recall there were some hacks to get around it, but I'v lost the links - anyone happen to know them?).

Overall, one might argue that having the entire codebase in single hierarchy binds the components too closely together - the current system is much more loose. However, the difference is that when building/developing the app, we want everything to be closely together, to help with maintainance; but when packaging for releases, we prefer to create separate packages - and that's also easier to do from single code tree. So it's a win-win situation.

Madcat, ZzZz

Comments: Post a Comment

<< Home

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