Libtorrent: CMake vcpkg patch

[FranciscoPombal]

Please provide the following information

libtorrent version (or branch):
latest RC_1_2

platform/architecture:
at least Windows amd64, possibly others.

compiler and compiler version:
not applicable, this is about CMake

please describe what symptom you see, what you would expect to see instead and
how to reproduce it.

What would be the consequences of applying this patch? https://github.com/microsoft/vcpkg/blob/master/ports/libtorrent/add-datetime-to-boost-libs.patch

Can it be applied here?

[arvidn]

well, I'm not a cmake expert. I'm pretty sure libtorrent doesn't depend on boost date-time though

[arvidn]

you don't think this is an artifact of how vcpkg packages boost?
what's the benefit of applying this?

[FranciscoPombal]

@arvidn Not sure either, I am by no means a CMake expert myself. It might very well just be an artifact of how vcpkg packages boost, like you say. But maybe it has to do with changes in the most recent versions of boost?

Besides the datetime change, what do you think about the other change? It could be just a more "modern" way of configuring boost in CMake, but my concern is if something else would break if that were applied.

Maybe we could ask someone else who is familiar with libtorrent and who has more CMake experience?

[arvidn]

my assumption about that change is that some header (transitively) includes a boost date time header, but none of the types defined in that header ends up being used anywhere in libtorrent.

I would argue that, technically, libtorrent depends on boost.asio (and a few other boost libraries), but cmake doesn't seem to be set up for dependencies on header-only libraries. Because whichever library includes date time, that should be the library that declares a dependency on boost.date-time.

[FranciscoPombal]

@arvidn what about this change?

-target_link_libraries(torrent-rasterbar PUBLIC ${Boost_SYSTEM_LIBRARY})
+target_link_libraries(torrent-rasterbar PUBLIC ${Boost_LIBRARIES})

[arvidn]

I defer to @zeule

[zeule]

${Boost_LIBRARIES} is robust as comparing to listing required components twice.

[zeule]

From the other hand, if tests or another component requires additional boost components, ${Boost_LIBRARIES} will create problems.

[FranciscoPombal]

@zeule thanks for the input.

From the other hand, if tests or another component requires additional boost components, ${Boost_LIBRARIES} will create problems.

Do you happen to know if this is the case for libtorrent? Or, should this be the case, is it more appropriate to keep it as is or invest in another kind of workaround for those other components that would otherwise fail?

[zeule]

For example, python bindings require boost::python. As for the date_time headers, boost requires a single (root) include directory, and we use it. Thus if another boost header includes a header from date_time, it works with the current setup. My guess the guys from vcpkg just slowpoking recalling times before std::chrono.