Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Boost] use cmake build #32309

Merged
merged 78 commits into from
Apr 29, 2024
Merged

Conversation

Neumann-A
Copy link
Contributor

@Neumann-A Neumann-A commented Jun 29, 2023

arm64-windows: boost-context builds are blocked by a cmake bug (see https://gitlab.kitware.com/cmake/cmake/-/issues/24317)

closes #32274
closes Neumann-A/my-vcpkg-triplets#5

Questions:

  • Move cmake files to share/cmake/<name> ? Not doing it because it is just using vcpkg_cmake_config_fixup()
  • Fix weak dependencies (uwp|emscripten|android|arm)?
  • Fix library names on !x64 (currently hardcoded to x64 or x86; failure in aricpp since it forces FindBoost module mode.)
  • Fix arm64-windows boost-context builds -> requires CMake (3.19.2?) update due to bug how the assembler is invoked. (-> CI baseline for now)

TODO:

@Cheney-W Cheney-W added the category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist label Jun 30, 2023
@Neumann-A
Copy link
Contributor Author

Neumann-A commented Jul 3, 2023

Hm I am properly not going to have time to analyse what is going on with all those dependent port regressions for a while.

E.g.: cpprestsdk fails due to:

Could NOT find Boost (missing: system date_time regex) (found version
  "1.82.0")

however locally it builds (CMake 3.26). I assume it has to do with the warning :

CMake Warning at D:/downloads/tools/cmake-3.25.1-windows/cmake-3.25.1-windows-i386/share/cmake-3.25/Modules/FindBoost.cmake:1384 (message):
  New Boost version may have incorrect or missing dependencies and imported
  targets

@Neumann-A
Copy link
Contributor Author

Neumann-A commented Jul 5, 2023

Probably wrong dep:

Building ismrmrd:x64-windows...
error: building ismrmrd:x64-windows failed with: CASCADED_DUE_TO_MISSING_DEPENDENCIES
    due to the following missing dependencies:
        boost[core]:x64-windows
Building rbdl:x64-windows...
error: building rbdl:x64-windows failed with: CASCADED_DUE_TO_MISSING_DEPENDENCIES
    due to the following missing dependencies:
        boost[core]:x64-windows

@Neumann-A
Copy link
Contributor Author

hmm boost-graph-parallel in CI:

-- Found MPI_CXX: D:/installed/x64-windows-static-md/lib/msmpi.lib (found version "2.0") 
-- Found MPI: TRUE (found version "2.0") found components: CXX 
Exit code 0xc0000409

ninja: build stopped: subcommand failed.

rest of x64-windows regressions is due to boost-math missing the old tr1 and c99 libs.

JavierMatosD
JavierMatosD previously approved these changes Apr 24, 2024
include("${CMAKE_CURRENT_LIST_DIR}/ref_sha.cmake")

vcpkg_from_github(
OUT_SOURCE_PATH SOURCE_PATH_SUPER
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to separate the vcpkg helpers from proper separate boost component (https://github.com/boostorg/cmake). Separating the vcpkg helper functions into a separate port makes the ownership clear. i.e., these are helper functions authored by vcpkg to package boost, this is the boostorg/cmake core project).

For example, the boost-cmake port is under the BSL-1.0 license and not under vcpkg's MIT license.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example, the boost-cmake port is under the BSL-1.0 license and not under vcpkg's MIT license.

Interesting question:
Should I mark the port with license null since the patches required for vcpkg are probably under MIT?

Please add it to the maintainer guidelines if you generally want this separation since I prefer it this way if the helper functions only have functionality for a certain very limited group of ports like here or in the case of qt. Secondly, adding a helper port here means that the required cmake logic gets kind of seperated.
How should i call the helper port vcpkg-boost(-(scripts|install|helpers))? Am I at least allowed to chain it via vcpkg-port-config through boost-cmake (avoids the issue to add it to all boost manifests)?

You probably only noticed it because boost-cmake replaces boost-modular-build-helper according to the git diff github shows ;)

# 1: boost-cmake/ref_sha.cmake needs manual updating
# 2: Do not trust this script. Platform expressions in dependencies are blindly applied.
# So if you see a configure log with that another boost<lib>Config.cmake is missing
# You probably trusted this script too much. Example: boost-graph -> requires boost-random
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment here should only define what does not work. I.e., no " Do not trust this script... You probably trusted this script too much."

scripts/boost/generate-ports.ps1 Outdated Show resolved Hide resolved
scripts/boost/generate-ports.ps1 Outdated Show resolved Hide resolved
ports/boost-cmake/usage.in Outdated Show resolved Hide resolved
ports/rbdl/vcpkg.json Outdated Show resolved Hide resolved
ports/spirit-po/vcpkg.json Outdated Show resolved Hide resolved
@@ -0,0 +1,38 @@
diff --git a/include/BoostInstall.cmake b/include/BoostInstall.cmake
index 3a00c16..069dde0 100644
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why aren't these changes upstream-able?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

except for

+      else()
+        string(SUBSTRING "${CMAKE_SYSTEM_PROCESSOR}" 0 1 arch)
+        string(TOLOWER "${arch}" arch)

this is already upstreamed
boostorg/cmake#57
These lines are missing due to boostorg/cmake#57 (comment)

@@ -0,0 +1,109 @@
diff --git a/CMakeLists.txt b/CMakeLists.txt
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this patch needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because a few ports in vcpkg want to use the legacy boost math libraries.
A follow up PR could make building those a feature instead and then mark the appropriate downstream ports explicitly so that boost-math is header only for most users.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JavierMatosD JavierMatosD marked this pull request as draft April 25, 2024 13:11
@Neumann-A Neumann-A marked this pull request as ready for review April 25, 2024 15:26
@Neumann-A
Copy link
Contributor Author

@Cheney-W there was a reason i did not yet merge with master. the baseline is broken. #37119 has a fix for that

@Neumann-A
Copy link
Contributor Author

@JavierMatosD: Are there any points I missed to address? I would like to make this ready to merge today.
CI should be green after the last merge with master since 3c18789 only showed the known baseline regression

@JavierMatosD
Copy link
Contributor

@JavierMatosD: Are there any points I missed to address? I would like to make this ready to merge today. CI should be green after the last merge with master since 3c18789 only showed the known baseline regression

Nope looks good to me! Thanks!

@JavierMatosD JavierMatosD merged commit bcf3d00 into microsoft:master Apr 29, 2024
17 checks passed
@Neumann-A Neumann-A deleted the boost-cmake-build branch April 29, 2024 20:02
yurybura pushed a commit to yurybura/vcpkg that referenced this pull request May 8, 2024
~~arm64-windows: boost-context builds are blocked by a cmake bug (see
https://gitlab.kitware.com/cmake/cmake/-/issues/24317)~~

closes microsoft#32274
closes Neumann-A/my-vcpkg-triplets#5

Questions:
- [x] ~~Move cmake files to `share/cmake/<name>` ?~~ Not doing it
because it is just using `vcpkg_cmake_config_fixup()`
- [x] Fix weak dependencies (uwp|emscripten|android|arm)?
- [x] Fix library names on !x64 (currently hardcoded to x64 or x86;
failure in aricpp since it forces FindBoost module mode.)
- [x] ~~Fix arm64-windows boost-context builds -> requires CMake
(3.19.2?) update due to bug how the assembler is invoked.~~ (-> CI
baseline for now)

TODO:
- [x] adjust generate ports script
- [x] microsoft#37457

---------

Co-authored-by: Cheney-Wang <850426846@qq.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist info:reviewed Pull Request changes follow basic guidelines
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[boost] Move to CMake [boost-regex] Build error (toolset path with spaces)