libtorrent icon indicating copy to clipboard operation
libtorrent copied to clipboard

meson: add

Open neheb opened this issue 7 months ago • 11 comments

Significantly faster than autotools thanks to Ninja and shorter code.

https://github.com/rakshasa/libtorrent/pull/390 was rejected because of speed. This is much faster.

Unfortunately, there seems to be an issue where the tests fail:

stderr:
test_tracker_list.cc:370:Assertion
Test name: test_tracker_list::test_scrape_success
assertion failed
- Expression: tracker_0.is_busy()

test_thread.cc:90:Assertion
Test name: test_tracker_list::test_scrape_failure
assertion failed
- Expression: torrent::utils::Thread::trylock_global_lock()

test_thread.cc:90:Assertion
Test name: test_tracker_list::test_has_active
assertion failed
- Expression: torrent::utils::Thread::trylock_global_lock()

test_thread.cc:90:Assertion
Test name: test_tracker_list_features::test_new_peers
assertion failed
- Expression: torrent::utils::Thread::trylock_global_lock()

test_thread.cc:90:Assertion
Test name: test_tracker_list_features::test_has_active
assertion failed
- Expression: torrent::utils::Thread::trylock_global_lock()

test_thread.cc:90:Assertion
Test name: test_tracker_list_features::test_find_next_to_request
assertion failed
- Expression: torrent::utils::Thread::trylock_global_lock()

test_thread.cc:90:Assertion
Test name: test_tracker_list_features::test_find_next_to_request_groups
assertion failed
- Expression: torrent::utils::Thread::trylock_global_lock()

test_thread.cc:90:Assertion
Test name: test_tracker_list_features::test_count_active
assertion failed
- Expression: torrent::utils::Thread::trylock_global_lock()

I've wasted hours trying to replicate autotools at this point to no avail.

The issue here might also be what's wrong with the BSDs. It's just now happening everywhere.

meson's pkgconfig file adds links to libcrypto and pthread, as it should.

subprojects available for zlib and libkqueue. None for cppunit unfortunately. Would allow testing on OmniOS.

neheb avatar Apr 22 '25 04:04 neheb

If this gets merged, it means I need to keep two build systems up-to-date in order to merge PRs.

And one of them I have no experience with.

This is still a completely unacceptable solution.

rakshasa avatar Apr 22 '25 07:04 rakshasa

I would recommend adding cmake instead as a build solution. It's entirely optional, widely used and easily understandable.

stickz avatar Apr 22 '25 10:04 stickz

I would recommend adding cmake instead as a build solution. It's entirely optional, widely used and easily understandable.

I disagree with this. I'm not wasting more hours reimplementing the build.

neheb avatar Apr 22 '25 19:04 neheb

If this gets merged, it means I need to keep two build systems up-to-date in order to merge PRs.

And one of them I have no experience with.

This is still a completely unacceptable solution.

Sure. I've marked it as draft.

neheb avatar Apr 22 '25 19:04 neheb

I would recommend adding cmake instead as a build solution. It's entirely optional, widely used and easily understandable.

Still suffers the issue of adding indeterminate future overhead for very little real-world benefit.

This started as a big endian platform test build PR and morphed into a replacement (or rather, duplication) of the whole build system.

Experience would make you say early on that this is a bad idea, and if really needed should be maintained separately outside of the main repository.

If replacing the build system made sense, it would make so on the merits of how it is better in the general case. Not merely to add support for a single platform

rakshasa avatar Apr 22 '25 19:04 rakshasa

to be fair I've had this locally for a long time. Adding libkqueue support allowed testing with that code path. I cleaned it up to match autotools as much as possible, in addition to some PRs cleaning up old autotools stuff.

The big endian thing is not related.

The main configure.ac clocks in at 118 lines. The main meson.build file is 136, which takes functionality from the various scripts. I think there's something to be said for simplicity.

neheb avatar Apr 22 '25 20:04 neheb

The failures are now:

test_tracker_list.cc:370:Assertion
Test name: test_tracker_list::test_scrape_success
assertion failed
- Expression: tracker_0.is_busy()

tracker_test.cc:168:Assertion
Test name: test_tracker_list::test_scrape_failure
assertion failed
- Expression: is_busy() && is_open()

test_tracker_list.cc:487:Assertion
Test name: test_tracker_list::test_has_active
assertion failed
- Expression: "01110"[2] == '0' || tracker_2.is_busy()

???

neheb avatar May 03 '25 00:05 neheb

ummm this is interesting.

by adding 3 extra files that i missed, tests succeed now. Wow what a waste of time that was.

neheb avatar May 10 '25 21:05 neheb

sped up test compilation. It matters on slow platforms.

neheb avatar May 26 '25 20:05 neheb

got execinfo working on BSDs: https://github.com/neheb/libtorrent/actions/runs/15262288336

neheb avatar May 26 '25 23:05 neheb

All platforms are now green: https://github.com/neheb/libtorrent/actions/runs/15289713193

neheb avatar May 28 '25 01:05 neheb

libatomic linking fixed.

neheb avatar Jul 01 '25 22:07 neheb