[xgboost] Add open-source library xgboost to vcpkg

[DadanielZ]

Add open-source library xgboost to vcpkg
xgboost github repo: https://github.com/dmlc/xgboost/

• Changes comply with the maintainer guide.
• The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
• Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx.
• 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 accurate. See adding-usage for context.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is in the new port's versions file.
• Only one version is added to each modified port's versions file.

[dg0yt]

Is this a windows-only limitation?
If yes, please guard with if(VCPKG_TARGET_IS_WINDOWS).
IMO it is also better (and common practice) to put this to the op of the file.

[DadanielZ]

I don't know if this is windows-only limitation. My build was on windows, without this vcpkg_check_linkage the vcpkg build will fail, and it failed because build was looking for "dmlc-core/dmlc.lib" during the link process, but only "dmlc-core/dmlc.dll" was generated in previous build process.

[dg0yt]

Any executables to be handled?

[DadanielZ]

@dg0yt thank you for the review. Not sure if I understand, what executables you were referring to? This code snippet was added based on the post-build check's warnings and its fix suggestions.

[dg0yt]

Given that the directory was created, I suspect that it was created to install either exectuables or DLLs.
In the case of executables, this approach would create inconsistent behavior for static vs dynamic. vcpk_copy_tools(... AUTO_CLEAN) would give consistent behavior.
In the case of DLLs, they must either be necessary, or they indicate insufficient control of library linkage.

[DadanielZ]

@dg0yt the generated files under "${CURRENT_PACKAGES_DIR}/bin" and "${CURRENT_PACKAGES_DIR}/debug/bin" are two files: xgboost.exe and xgboost.dll.
I replaced the above code with vcpk_copy_tools but I see the same warning and the same suggestion to remove the bin and debug/bin folders:
vcpkg_copy_tools( TOOL_NAMES xgboost SEARCH_DIR "${CURRENT_PACKAGES_DIR}/bin" "${CURRENT_PACKAGES_DIR}/debug/bin" AUTO_CLEAN )

warning: If the creation of bin\ and/or debug\bin\ cannot be disabled, use this in the portfile to remove them if(VCPKG_LIBRARY_LINKAGE STREQUAL "static") file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/bin" "${CURRENT_PACKAGES_DIR}/debug/bin") endif()

[dg0yt]

Suggested change

	if(VCPKG_LIBRARY_LINKAGE STREQUAL "static")
	file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/bin" "${CURRENT_PACKAGES_DIR}/debug/bin")
	endif()
	vcpkg_copy_tools(TOOL_NAMES xgboost AUTO_CLEAN)

must handles this, really.

[Urfoex]

Not sure, if it helps, but here is our overlay port of xgboost of version v2.0.3
xgboost.tar.gz

We are using it to build our application getML on Linux.

[dg0yt]

The x86 and arm64 logs seem to indicate problems with intrinsics IIUC. And uwp doesn't offer some of the windows API. Probably these triplets need to be excluded from supported.
There is also a warning

cl : Command line warning D9025 : overriding '/MTd' with '/MDd'

[hcho3]

@dg0yt Currently, XGBoost sets the MSVC link flags (/MT or /MD) by editing the raw build flags, an approach I feel is potentially problematic (dmlc/xgboost#10344). Do you think fixing this would help with distributing XGBoost on vcpkg?

[dg0yt]

Suggested change

	vcpkg_cmake_configure(
	SOURCE_PATH ${SOURCE_PATH}
	)
	string(COMPARE EQUAL "${VCPKG_CRT_LINKAGE}" "dynamic" FORCE_SHARED_CRT)
	vcpkg_cmake_configure(
	SOURCE_PATH ${SOURCE_PATH}
	OPTIONS
	-DFORCE_SHARED_CRT=${FORCE_SHARED_CRT}
	)

[dg0yt]

You just have to use the options it offers.
CMAKE_MSVC_RUNTIME_LIBRARY isn't used by the vcpkg toolchain which controls flags directly and still supports older versions of CMake.

[hcho3]

Got it. Would it be a problem for you if XGBoost would start using CMAKE_MSVC_RUNTIME_LIBRARY flag and require CMake 3.15 some time in the future?

[dg0yt]

Got it. Would it be a problem for you if XGBoost would start using CMAKE_MSVC_RUNTIME_LIBRARY flag and require CMake 3.15 some time in the future?

Nothing which couldn't be solved.
The key is that projects don't change flags which are meant do be set by the user or toolchain.