As of now libbtcore which used to be internal to ktorrent is split of into a separate library named libktorrent. This means that if you want to build trunk you need to do this:

svn co svn://anonsvn.kde.org/home/kde/trunk/ex ... ibktorrent
svn co svn://anonsvn.kde.org/home/kde/trunk/ex ... k/ktorrent

Build steps remain the same, only you need to do them twice, first for libktorrent and then for ktorrent:

cd libktorrent
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=$(kde4-config --prefix) ..
make
sudo make install
cd ../../ktorrent
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=$(kde4-config --prefix) ..
make
sudo make install

The first public release with the split will be 4.0rc1, so the just released 4.0beta2 is still one package.

Hi George,

last time I checked, libbtcore, which libktorrent originates from, was not written with binary compatibility in mind (i.e. it does not use d pointers and other techniques). I do understand that libktorrent is not kdelibs and it does not have to strictly keep BC, but I wonder if current design will not result into libktorrent breaking ABI and bumping soname each new minor (as opposed to major release like 4.0 -> 4.1) ktorrent release. Therefore, my question is whether you plan to develop libktorrent in a more BC friendly manner now.

I will take appropriate packaging decisions based on your answer since frequently changing sonames is typically painful to handle.

MoDaX wrote:Hi George,

last time I checked, libbtcore, which libktorrent originates from, was not written with binary compatibility in mind (i.e. it does not use d pointers and other techniques). I do understand that libktorrent is not kdelibs and it does not have to strictly keep BC, but I wonder if current design will not result into libktorrent breaking ABI and bumping soname each new minor (as opposed to major release like 4.0 -> 4.1) ktorrent release. Therefore, my question is whether you plan to develop libktorrent in a more BC friendly manner now.

I will take appropriate packaging decisions based on your answer since frequently changing sonames is typically painful to handle.

The goal is to keep things BC between minor releases. In the long run I want to stabilize the interface, so that soversion changes will be infrequent.

Any plans to make a headless "ktorrentd" suitable for seedboxes and the like?