[libxchange] initial port

[attipaci]

This is a draft PR with the upstream release candidate. Please comment on issues so they may be fixed upstream if need be. This PR will be updated to the final upstream v1.1.2 release in a couple of weeks, after which it may be merged as appropriate.

• Changes comply with the maintainer guide.
• The packaged project shows strong association with the chosen port name. Check this box if at least one of the following criteria is met:
  • The project is in Repology: https://repology.org//versions
  • The project is amongst the first web search results for "" or " C++". Include a screenshot of the search engine results in the PR.
  • The port name follows the 'GitHubOrg-GitHubRepo' form or equivalent Owner-Project form.
• Optional dependencies of the build are all controlled by the port. A dependency is controlled if it is declared an unconditional dependency in vcpkg.json, or explicitly disabled through patches or build system arguments such as CMAKE_DISABLE_FIND_PACKAGE_Xxx or VCPKG_LOCK_FIND_PACKAGE
• The versioning scheme in vcpkg.json matches what upstream says.
• The license declaration in vcpkg.json matches what upstream says.
• The installed as the "copyright" file matches what upstream says.
• The source code of the component installed comes from an authoritative source.
• The generated "usage text" is brief and accurate. See adding-usage for context. Don't add a usage file if the automatically generated usage is correct.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Exactly one version is added in each modified versions file.

[attipaci]

From the arm64_linux failure log:

CMake Error at CMakeLists.txt:80 (find_library):
  Could not find MATH_LIBRARY using the following names: m

libm is standard on Linux. It's strange that it seems to be missing for the arm64_linux build (but fine on the other Linux and non-Windows builds). Any help or insight is welcome on how this may be fixed.

[dg0yt]

For the arm64-linux cross build, libm is not in the standard paths searched by CMake's find_library. But it is in the paths searched by the C linker, CMAKE_C_IMPLICIT_LINK_DIRECTORIES.

Basically it is a bad idea to search for the path of libm because you are supposed to use -lm.

Related: #50514

[attipaci]

Thanks @dg0yt,

I've changed how the need for linking against the math library is determined. It's a bit strange that CMake does not have a more automatic portable way to link against the math library when needed for a given platform, given that it's likely to a very common use case and equally common source of mistakes that limit portability...

[vicroms]

Changes requested:

• docs and examples should not be installed

For consideration:

• This library is named libxchange on Repology

[vicroms]

Suggested change

	-DBUILD_TESTING=OFF
	-DBUILD_TESTING=OFF
	-DBUILD_DOC=OFF
	-DBUILD_EXAMPLES=OFF

The port is installing documentation and examples by default

xchange:<triplet>:/share/doc/xchange/CHANGELOG.md
xchange:<triplet>:/share/doc/xchange/CONTRIBUTING.md
xchange:<triplet>:/share/doc/xchange/examples/CMakeLists.txt
xchange:<triplet>:/share/doc/xchange/examples/example-escape.c
xchange:<triplet>:/share/doc/xchange/examples/Makefile
xchange:<triplet>:/share/doc/xchange/examples/example-json.c
xchange:<triplet>:/share/doc/xchange/examples/.gitignore

[attipaci]

Hi @vicroms,

Thanks for the feedback. I'll remove the doc and examples from the install. I'm also happy to call it libxchange (I was debating it in the first place). The original name is xchange (as in the Github repo, and the CMake package export), but that name was already taken by a once-upon-a-time Fedora package, hence it became libxchange for Linux.

[attipaci]

BUILD_DOC and BUILD_EXAMPLES are both OFF by default, so there is no need to set these explicitly. The examples (source code) and some bare basic documentation (e.g. CHANGELOG.md) are always installed in the docdir by upstream. Which means that the vcpkg port will have to explicitly remove these if they are unwanted. I've updated to portfile to remove the docdir contents installed by upstream. Hopefully that is sufficient.

[attipaci]

Nevertheless, the CMake package export from upstream is xchange, not libxchange. If that is confusing, then I think naming the vcpkg port as xchange (the same as the CMake package) might still be preferrable.

[BillyONeal]

Nevertheless, the CMake package export from upstream is xchange, not libxchange. If that is confusing, then I think naming the vcpkg port as xchange (the same as the CMake package) might still be preferrable.

We cite repology because we believe being consistent with other package managers is more important than being consistent with other identifiers.

[BillyONeal]

Please merge these nitpick fixes. attipaci#3

[BillyONeal]

I don't think Victor (@vicroms ) comment is fixed yet. If upstream exposes an option to disable building examples we should use it.

[attipaci]

Hi @BillyONeal,

I think I tried to answer @vicroms comments -- I clearly did not do a good job, so I'll ty again... ;-)

Upstream always installs the example source code (.c files) and the changelog and contributor guide (.md files) into the doc directory (<prefix>/share/doc/xchange/). Upstream has no options to disable these.

The BUILD_EXAMPLES option controls only whether or not the examples are also compiled into test programs during build, while the BUILD_DOC option controls whether additional HTML documentation is built using Doxygen. Both BUILD_EXAMPLES and BUILD_DOC are OFF by default, so @vicroms suggested changes have exactly zero effect on what is built / installed.

The only way to ensure that vcpkg does not have stuff installed in the docdir is to remove these after the upstream install. Which is the change I did implement.

I hope this clarifies it better.

-- A.

[BillyONeal]

Ah, I see the confusion now. I think what happened is that @vicroms saw "examples" in the file list, saw that upstream has a BUILD_EXAMPLES, and that that was not turned off when we invoke it, then wrote the comment.

The unconditional write is here:

https://github.com/Sigmyne/xchange/blob/0e3e3ec6d37317b0bd1f4a59f0fe1e05c4a23cfe/CMakeLists.txt#L140-L144

[BillyONeal]

Thank you!

They explained that that does not apply