[ libtorrent ] Update to 2.0

[JonLiu1993]

Fix #13702

Update libtorrent to 2.0

All featureas are tested successfully in the following triplets

• x86-windows
• x64-windows
• x64-windows-static

[FranciscoPombal]

Looks like the iconv patch is no longer needed either: https://github.com/arvidn/libtorrent/blob/4ea515281df328650d246ec662e8699e6a4d42a6/ChangeLog#L8

[JonLiu1993]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[JonLiu1993]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Convery]

The removal of ports/lua/portfile.cmake is accidental.
Otherwise working as expected on x86 but fails on x64.

Updating to the latest commit fixes it though:

vcpkg_from_github(
    OUT_SOURCE_PATH SOURCE_PATH
    REPO arvidn/libtorrent
    REF master
    SHA512 8205eca746a365a22702d0c3a02aa02438a8558e9ff1f5aa63788cb10233935dda2a3900d21abcdb13111f6d01337752dc0831000e5ded0eb4884f4fa4c736c8
    HEAD_REF RC_2.0
)

[FranciscoPombal]

2.0.1 was just released (https://github.com/arvidn/libtorrent/releases/tag/v2.0.1), as well as 1.2.11 (https://github.com/arvidn/libtorrent/releases/tag/v1.2.11). Wouldn't it be better to first update to 1.2.11, and only after that to 2.x?

[Convery]

Can always do both. 1.2.x wasn't updated since Sep so I just assumed that 2.0 was the current branch. Can always have two ports, one for libtorrent 1.x and one for 2.x, rather than a single libtorrent.

[JonLiu1993]

I will upgrade soon, thank you everyone

[glassez]

libtorrent-2.0 shouldn't be considered as update for this port. You should add another port for it (aka libtorrent2) and keep this one for 1.2.x.

[FranciscoPombal]

libtorrent-2.0 shouldn't be considered as update for this port. You should add another port for it (aka libtorrent2) and keep this one for 1.2.x.

I second this. There are still many projects that benefit from the continued support of the 1.x.x branches, and it is convenient to have them available without having to roll back vcpkg commits.

EDIT: or maybe the new version could be exposed via a feature (much the same way qt5[latest] works)? Anyway, I guess all of this will be easier to manage when proper versioning support lands, but for now, creating a new port seems to be the path of least resistance.

[JonLiu1993]

Duplicate to #14755