Add libtorrent dependency and minimal stub integration

[aviralgarg05]

Fixes #1238 (sub-issue of #1193)

• Add libtorrent-rasterbar as a hard dependency in meson.build
• Create minimal LibTorrent stub class in src/libtorrent.h and src/libtorrent.cpp
• Add getVersion() method to verify libtorrent integration works
• Create test/libtorrent.cpp with tests for instantiation, version retrieval, and linking
• Add boost include path for libtorrent header dependencies
• Update meson.build to check for mustache header in source tree
• Add mustache.hpp header to include directory

[kelson42]

@aviralgarg05 Thank you for your first PR. My first remark, and this is about something very important, we have to rely on official libtorrent (and not on the rasterbar fork). Any very strong reason to go for this minor fork?

[aviralgarg05]

@aviralgarg05 Thank you for your first PR. My first remark, and this is about something very important, we have to rely on official libtorrent (and not on the rasterbar fork). Any very strong reason to go for this minor fork?

I think libtorrent-rasterbar IS the official libtorrent library from github.com/arvidn/libtorrent. The "rasterbar" name comes from the project's origins. This is the correct pkg-config name used on all platforms.

[kelson42]

@aviralgarg05 Thank you for your first PR. My first remark, and this is about something very important, we have to rely on official libtorrent (and not on the rasterbar fork). Any very strong reason to go for this minor fork?

I think libtorrent-rasterbar IS the official libtorrent library from github.com/arvidn/libtorrent. The "rasterbar" name comes from the project's origins. This is the correct pkg-config name used on all platforms.

I´m not an expert of this library either but:

• If you look at https://github.com/airium/libtorrent-rasterbar, you see this is a fork of https://github.com/arvidn/libtorrent
• https://github.com/arvidn/libtorrent has far more stars/contributions than libtorrent-rasterbar

[aviralgarg05]

@aviralgarg05 Thank you for your first PR. My first remark, and this is about something very important, we have to rely on official libtorrent (and not on the rasterbar fork). Any very strong reason to go for this minor fork?

I think libtorrent-rasterbar IS the official libtorrent library from github.com/arvidn/libtorrent. The "rasterbar" name comes from the project's origins. This is the correct pkg-config name used on all platforms.

I´m not an expert of this library either but:

• If you look at https://github.com/airium/libtorrent-rasterbar, you see this is a fork of https://github.com/arvidn/libtorrent
• https://github.com/arvidn/libtorrent has far more stars/contributions than libtorrent-rasterbar

Thank you for pointing this out! I understand the confusion now. The libtorrent-rasterbar package name does indeed refer to the official libtorrent library from [https://github.com/arvidn/libtorrent].

The "rasterbar" part comes from Rasterbar Software, which is Arvid Norberg's company that develops and maintains libtorrent. Looking at the repositories:

[https://github.com/arvidn/libtorrent]: The official repository with 5.8k stars, 1.1k forks, 137 contributors, and active development (latest release v2.0.11 on Jan 28)
[https://github.com/airium/libtorrent-rasterbar]: A minor personal fork with only 13 stars, 1 fork, and no releases published
The pkg-config name libtorrent-rasterbar is the standard name used across Linux distributions and package managers for the official library. This is confirmed by:

The official libtorrent website [https://libtorrent.org/] which links to the arvidn/libtorrent repository
Package listings on Repology [https://repology.org/project/libtorrent-rasterbar/versions] showing 206 packages across major distributions (Alpine, Arch, Debian, Fedora, Ubuntu, etc.) all using libtorrent-rasterbar for the official library
Our successful meson build that finds and links against libtorrent-rasterbar version 2.0.11

So we are definitely using the official libtorrent library, not a fork. The naming convention just reflects the company behind the project.

The airium fork appears to be a personal project with minimal activity and no official status.

[kelson42]

@veloman-yunkan After a first looks it looks good to me, at least it compiles and I don't see any obvious strange thing. Can you please have a look on your side?

We need as well to:

• Implement Add libtorrent dependency to kiwix-build kiwix-build#890 to get the CI passing
• Decide if we want to merge this BitTorrent related thing to a dedicated branch or directly on main.

[veloman-yunkan]

@aviralgarg05

First of all I would like to thank you for your interest in contributing to libkiwix.

At the same time my feeling is that you picked up the wrong task for getting started with our projects. In its current form (though I see that it's merely a draft) this PR is of low value and I am afraid that it will result in mutual disappointment if the work on it continues. Adding a new dependency that is going to replace the underlying implementation (aria2) of a major component (kiwix::Downloader) that has no unit-tests is a serious undertaking. It requires good understanding of both our build infrastructure and how kiwix::Downloader is used in kiwix-desktop (part of it being nothing else than workarounds of aria2's limitations). I advise you to get your feet wet with libkiwix through another issue with quicker turnaround times for tangible results.

[veloman-yunkan]

We already have mustache.hpp in our dependencies (Update: I see that the added file was removed in the next commit, but in a clean version of the PR it shouldn't have been added at all).