Update build condition for tests in CMakeLists

[hoshiizumiya]

TORRENT_EXPORT_EXTRA is currently enabled only as part of the build_tests block.

Some examples and tools also call internal APIs marked with TORRENT_EXTRA_EXPORT. With BUILD_SHARED_LIBS=ON and either build_examples=ON or build_tools=ON, but build_tests=OFF, those functions are therefore not exported from torrent-rasterbar.

This causes linker errors on Windows shared builds. For example, connection_tester references several merkle_* functions marked with TORRENT_EXTRA_EXPORT, but they are missing from the DLL import library.

Enable TORRENT_EXPORT_EXTRA whenever tests, examples, or tools are built, while keeping add_subdirectory(test) conditional on build_tests.

Found while updating the vcpkg libtorrent port to 2.1.1: microsoft/vcpkg#53354

[arvidn]

TORRENT_EXPORT_EXTRA should really only be set when testing. just building examples should not cause these internal functions and classes to be exported.

I recognize that connection_tester does use internal functions. I think connection_tester is the problem, not the fact that internal functions aren't being exported.

[hoshiizumiya]

Thanks, that makes sense.

I also saw the same issue with build_tools in the vcpkg feature tests. tools/checking_benchmark.cpp includes aux_/path.hpp and calls lt::stat_file(), which is also marked TORRENT_EXTRA_EXPORT.

So it looks like there are at least two targets relying on these internal exports:

examples/connection_tester uses the internal merkle_* helpers
tools/checking_benchmark uses the internal stat_file

Would you prefer these targets to be refactored to avoid the internal APIs, or should internal-only targets be skipped when building against the shared library?

I can update this PR accordingly.

[arvidn]

I would expect that the vcpkg really only cares about the main library target, right?
But in general, I think it's fine to exclude some of the tools and example targets that are using internal functions for now. I'm starting to use std::filesystem in examples and tools (but not in the main library yet, as I believe MacOS may be lagging in its support).

I think the merkle helper functions are so small that they could probably just be re-implemented in the tool that needs them.

[hoshiizumiya]

You're right. The vcpkg main usage is the core feature. Since this only affects auxiliary example/tool targets in shared builds, I'll keep the current extra-export change as a small downstream workaround in the vcpkg port for now 2.1.1 rather than changing the upstream DLL interface.

Once connection_tester no longer depends on the internal Merkle helpers and checking_benchmark moves away from the internal filesystem helpers, the downstream patch can simply be removed.

We can create an issue to track it.