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

cmake: Rework handling compiler flags #82

Merged
merged 2 commits into from
Mar 25, 2024
Merged

Conversation

hebasto
Copy link
Owner

@hebasto hebasto commented Jan 24, 2024

  1. Use standard CMake's way to pass flags from depends to the main build system using CMAKE_<LANGUAGE>_FLAGS_INIT variables instead of custom DEPENDS_<LANGUAGE>_COMPILER_FLAGS ones. This guaranties using those flags during various checks at the configuration stage.

  2. Setting flags is decoupled from setting compilers in the toolchain file.

  3. Per-configuration flags are cached properly.

  4. No longer needed to set -DCMAKE_BUILD_TYPE=None when building with depends.

Fixes cross compilation for macOS.

Allows the user to use {C,CXX}FLAGS environment variables for depends and the main build system without drawbacks/workarounds.

The flags presentation in the summary (#82 (comment)) will be reworked in a separated PR.

@hebasto
Copy link
Owner Author

hebasto commented Jan 25, 2024

Added a new commit, which suggests a middle-ground, i.e. reordering flags from the CMAKE_<LANG>_FLAGS and CMAKE_<LANG>_FLAGS_<CONFIG> variables.

@hebasto hebasto marked this pull request as ready for review January 25, 2024 11:40
@fanquake
Copy link

It's not really clear to me from the PR description what is changing, or how someone should/would use the build system after this change. Do standard C/CXX/LD flags still work? Are they equivalent to CMAKE_<LANG>_FLAGS? Can things still be overriden when doing a depends build? What happens when flags are set in the envionment etc?

FWIW, the libsecp repo uses a bit different bitcoin-core/secp256k1#1249.

I don't really like this approach at all. We shouldn't have to make up non-standard flags/env vars just to do basic configuration of a build system.

@hebasto
Copy link
Owner Author

hebasto commented Jan 25, 2024

Do standard C/CXX/LD flags still work?

The CFLAGS and CXXFLAGS environment variables still take part in forming the initial values of the CMAKE_C_FLAGS and CMAKE_CXX_FLAGS if they are not set explicitly by the user or a toolchain file (exactly as documented by CMake).


Are they equivalent to CMAKE_<LANG>_FLAGS?

No, and have never been. https://discourse.cmake.org/t/strictly-appending-to-cmake-lang-flags/6478/5:

the difference between CMAKE_CXX_FLAGS and CXXFLAGS is intentional. The flags are stored in the CMAKE_CXX_FLAGS cache entry, and the default value for that is taken from a combination of builtin flags and the CXXFLAGS environment variable. By specifying -DCMAKE_CXX_FLAGS=... one says “use my flags instead of the defaults”.


Can things still be overriden when doing a depends build? What happens when flags are set in the envionment etc?

The CMAKE_C_FLAGS and CMAKE_CXX_FLAGS variables still can be used to override default flags, including those that provided by a toolchain file (exactly as documented by CMake).

@hebasto
Copy link
Owner Author

hebasto commented Jan 27, 2024

Rebased.

@hebasto hebasto added help wanted Extra attention is needed question labels Jan 27, 2024
@TheCharlatan
Copy link

TheCharlatan commented Jan 28, 2024

Not sure about this patch. It is currently misreporting the contents of the CXXFLAGS variable (skipping over the duplicate prepended part), and still does not handle the instrumentation options that are currently reported under Common compile options. Should we really be fighting the build system this hard?

If providing an empty configuration in combination with environment variables, or passing the mentioned build-type suffixed arguments -DCMAKE_CXX_FLAGS_DEBUG are common practices that package managers are already using, so I'm not sure why we are trying to shoehorn a different solution to it. Then again existing practices are less convenient, because they force the user to provide the full set of flags, instead of just appending to them.

Alternatively we could lean in to it and provide more build type configurations, or cmake presets as the need arises. I get that presets are only supported starting cmake 3.19, but it is something that users could opt in to.

@hebasto
Copy link
Owner Author

hebasto commented Jan 28, 2024

We discussed this with @TheCharlatan offline.

Should we really be fighting the build system this hard?

No, we shouldn't. Following the accepted CMake practices is more future-proof way.

... why we are trying to shoehorn a different solution to it.

The only reason, at least for me, was to achieve 100% compatible to the current build system behavior.


This PR has been updated to leverage native CMake practices.

@hebasto
Copy link
Owner Author

hebasto commented Jan 30, 2024

I have another argument in support of the current PR branch. The CMAKE_CXX_FLAGS are considered when using the CheckCXXSourceCompiles command (and its friends). This is essential for cross-compiling for macOS, because otherwise the following output might be produced:

ld: warning: building for macOS 10.4.0 is deprecated
ld: -pie requires targetting a newer minimum version

@fanquake
Copy link

ld: warning: building for macOS 10.4.0 is deprecated
ld: -pie requires targetting a newer minimum version

Both of these sound like a problem of not setting a proper minimum version, that shouldn't be the case when we are cross-compiling, because the minimum version is set in our c and cxx flags? Is this only an issue with the current CMake branch?

@hebasto
Copy link
Owner Author

hebasto commented Jan 30, 2024

ld: warning: building for macOS 10.4.0 is deprecated
ld: -pie requires targetting a newer minimum version

Both of these sound like a problem of not setting a proper minimum version, that shouldn't be the case when we are cross-compiling, because the minimum version is set in our c and cxx flags? Is this only an issue with the current CMake branch?

Yes. This PP is a bug fix.

@theuni
Copy link

theuni commented Jan 31, 2024

Just a quick comment as I review: it would be very helpful to add more meaningful commit messages to the fixup commits. I understand that they'll be squashed away eventually, but it would save reviewers some time trying to figure out exactly what is being fixed by each one.

@hebasto
Copy link
Owner Author

hebasto commented Feb 1, 2024

Just a quick comment as I review: it would be very helpful to add more meaningful commit messages to the fixup commits. I understand that they'll be squashed away eventually, but it would save reviewers some time trying to figure out exactly what is being fixed by each one.

Sure. The commit messages have been improved.

@fanquake
Copy link

fanquake commented Feb 1, 2024

Is there are reason C & CXX FLAGS are in two different places in the output:

CFLAGS ................................ -O3 -flto
C++ compiler .......................... /Library/Developer/CommandLineTools/usr/bin/c++
CXXFLAGS .............................. -O3 -flto
Common compile options ................ -Wstack-protector -fstack-protector-all -mbranch-protection=bti
Common link options ................... -Wl,-dead_strip -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -Wl,-fixup_chains
Linker flags for executables .......... 
Linker flags for shared libraries ..... 
Build type (configuration):
 - CMAKE_BUILD_TYPE ................... RelWithDebInfo
 - Preprocessor defined macros ........ 
 - CFLAGS ............................. -O2 -g
 - CXXFLAGS ........................... -O2 -g
 - LDFLAGS for executables ............ 
 - LDFLAGS for shared libraries ....... 

This is confusing, and it also means you don't actually know the flag ordering? i.e in this case. Is -O2 being used, or -O3?

@hebasto
Copy link
Owner Author

hebasto commented Feb 1, 2024

This is confusing, and it also means you don't actually know the flag ordering? i.e in this case. Is -O2 being used, or -O3?

The flag ordering is known: configuration-agnostic flags are followed by the configuration-specific one. That's why the have the same order in the summary.

Also please consider multi-configuration support:

$ cmake -B build -G "Ninja Multi-Config"
...
Cross compiling ....................... FALSE
Preprocessor defined macros ........... 
C compiler ............................ /usr/bin/cc
CFLAGS ................................ 
C++ compiler .......................... /usr/bin/c++
CXXFLAGS .............................. 
Common compile options ................ -fno-extended-identifiers -fstack-reuse=none -Wstack-protector -fstack-protector-all -fcf-protection=full -fstack-clash-protection
Common link options ................... -Wl,-z,relro -Wl,-z,now -Wl,-z,separate-code
Linker flags for executables .......... 
Linker flags for shared libraries ..... 
Available build types (configurations)  RelWithDebInfo Debug Release
'RelWithDebInfo' build type (configuration):
 - Preprocessor defined macros ........ 
 - CFLAGS ............................. -O2 -g
 - CXXFLAGS ........................... -O2 -g
 - LDFLAGS for executables ............ 
 - LDFLAGS for shared libraries ....... 
'Debug' build type (configuration):
 - Preprocessor defined macros ........ DEBUG DEBUG_LOCKORDER DEBUG_LOCKCONTENTION RPC_DOC_CHECK ABORT_ON_FAILED_ASSUME
 - CFLAGS ............................. -O0 -g3
 - CXXFLAGS ........................... -O0 -ftrapv -g3
 - LDFLAGS for executables ............ 
 - LDFLAGS for shared libraries ....... 
'Release' build type (configuration):
 - Preprocessor defined macros ........ 
 - CFLAGS ............................. -O2
 - CXXFLAGS ........................... -O2
 - LDFLAGS for executables ............ 
 - LDFLAGS for shared libraries ....... 
Use assembly routines ................. ON
Attempt to harden executables ......... ON
Treat compiler warnings as errors ..... OFF
Use ccache for compiling .............. ON

@fanquake
Copy link

fanquake commented Feb 1, 2024

The flag ordering is known: configuration-agnostic flags are followed by the configuration-specific one.

Sure, but this isn't obivous or intuitive. Is there any reason we can't have a single line of the compiler flags that are going to be used, with clear ordering. Rather than having multiple lines, and ambiguity.

@hebasto
Copy link
Owner Author

hebasto commented Feb 1, 2024

The flag ordering is known: configuration-agnostic flags are followed by the configuration-specific one.

Sure, but this isn't obivous or intuitive. Is there any reason we can't have a single line of the compiler flags that are going to be used, with clear ordering. Rather than having multiple lines, and ambiguity.

Added a commit, which addresses @fanquake's comment.

@hebasto
Copy link
Owner Author

hebasto commented Feb 1, 2024

Is there are reason C & CXX FLAGS are in two different places in the output:

CFLAGS ................................ -O3 -flto
C++ compiler .......................... /Library/Developer/CommandLineTools/usr/bin/c++
CXXFLAGS .............................. -O3 -flto
Common compile options ................ -Wstack-protector -fstack-protector-all -mbranch-protection=bti
Common link options ................... -Wl,-dead_strip -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -Wl,-fixup_chains
Linker flags for executables .......... 
Linker flags for shared libraries ..... 
Build type (configuration):
 - CMAKE_BUILD_TYPE ................... RelWithDebInfo
 - Preprocessor defined macros ........ 
 - CFLAGS ............................. -O2 -g
 - CXXFLAGS ........................... -O2 -g
 - LDFLAGS for executables ............ 
 - LDFLAGS for shared libraries ....... 

This is confusing, and it also means you don't actually know the flag ordering? i.e in this case. Is -O2 being used, or -O3?

$ CFLAGS="-O3 -flto" CXXFLAGS="-O3 -flto" cmake -B build -DCMAKE_BUILD_TYPE=None
...
Cross compiling ....................... FALSE
Preprocessor defined macros ........... 
C compiler ............................ /usr/bin/cc
C++ compiler .......................... /usr/bin/c++
Common compile options ................ -fno-extended-identifiers -fstack-reuse=none -Wstack-protector -fstack-protector-all -fcf-protection=full -fstack-clash-protection
Common link options ................... -Wl,-z,relro -Wl,-z,now -Wl,-z,separate-code
Build type (configuration):
 - CMAKE_BUILD_TYPE ................... None
 - Preprocessor defined macros ........  
 - CFLAGS ............................. -O3 -flto 
 - CXXFLAGS ........................... -O3 -flto 
 - LDFLAGS for executables ............  
Use assembly routines ................. ON
Attempt to harden executables ......... ON
Treat compiler warnings as errors ..... OFF
Use ccache for compiling .............. ON

@fanquake
Copy link

fanquake commented Feb 1, 2024

This is better, but I still think we can improve this. It's still not clear why c and cxxflags are separete from common compile options. They are also "common compile options" ?

@hebasto
Copy link
Owner Author

hebasto commented Feb 1, 2024

This is better, but I still think we can improve this. It's still not clear why c and cxxflags are separete from common compile options. They are also "common compile options" ?

CMake treats CFLAGS, CXXFLAGS, CMAKE_<LANG>_FLAGS and CMAKE_<LANG>_FLAGS_<CONFIG> using the following rules:

  1. They are considered as mere strings.
  2. They are considered language-wide, hence are used for linker invocations as well.

Common compile/link options are encapsulated in the core_interface library, which means that "compile" options will be passed to a compiler only and never to a linker.

@hebasto hebasto force-pushed the 240124-cmake-AZ branch 3 times, most recently from b8af63f to d4a99f5 Compare February 5, 2024 08:25
@hebasto
Copy link
Owner Author

hebasto commented Feb 5, 2024

Reworked. The PR description updated.

-e 's|@CFLAGS@|$(strip $(host_CFLAGS) $(host_$(release_type)_CFLAGS))|' \
-e 's|@CXXFLAGS@|$(strip $(host_CXXFLAGS) $(host_$(release_type)_CXXFLAGS))|' \
-e 's|@CPPFLAGS@|$(strip $(host_CPPFLAGS) $(host_$(release_type)_CPPFLAGS))|' \
-e 's|@CFLAGS@|$(strip $(host_CFLAGS))|' \
Copy link

Choose a reason for hiding this comment

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

We are only doing 1 type of build at a time, so why do we need to split all of this up into 3 different variables for each flag? This wont scale if there are more build types added in the future (which could be a possibility with the use of presets etc)?

Copy link
Owner Author

Choose a reason for hiding this comment

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

The goal is to convey build type specific flags to the CMAKE_<LANGUAGE>_FLAGS_<CONFIG> variable, not to CMAKE_<LANGUAGE>_FLAGS. Combined with other changes in this PR, this fixes the issue with overriding optimisation flags form depends with per-configure flags. That means, no need to use the non-documented "None" build type any more.

@hebasto
Copy link
Owner Author

hebasto commented Feb 9, 2024

Rebased.

@hebasto hebasto added the bug Something isn't working label Feb 10, 2024
@theuni
Copy link

theuni commented Feb 20, 2024

Trying to get my head around this in the next few days.

@hebasto
Copy link
Owner Author

hebasto commented Mar 4, 2024

Rebased.

Copy link

@pablomartin4btc pablomartin4btc left a comment

Choose a reason for hiding this comment

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

Perhaps it's already clear for you and I'm just not used to it yet but we shouldn't make it more explicit in the summary what are the defaults/ initial values (CFLAGS and CXXFLAG, eg: replace_cxx_flag_in_config(Debug -g -g3)), the values set by the user (eg DCMAKE_CXX_FLAGS=) and the ones set at compiling depends time (CMAKE_<LANGUAGE>_FLAGS_INIT)?

Like which ones are getting replaced/ overriden or don't match (eg when compiler diagnostic flags are added - #84).

I do agree with @TheCharlatan on the presets at some point in the future if possible + that the user also could still add flags (if possible).

@hebasto
Copy link
Owner Author

hebasto commented Mar 8, 2024

Rebased.

@hebasto hebasto force-pushed the 240124-cmake-AZ branch 2 times, most recently from 3cf702f to fe87888 Compare March 17, 2024 16:17
@hebasto
Copy link
Owner Author

hebasto commented Mar 18, 2024

There are a few way to justify this branch changes:

  • It works with Guix builds.
  • It works with OSS-Fuzz.
  • It works with our CI (see this new WIP branch).

To recap the CMake's logic, let's consider C++ compiler flags only for brevity:

  1. The CXXFLAGS environment variable adds flags.
  2. The CMAKE_CXX_FLAGS and CMAKE_CXX_FLAGS_<CONFIG> CMake variables override flags.

Interacting with own depends build system is quite a unique property I did not find in other open source projects that uses CMake. It is basically cross-compiling, which implies using toolchain files.

It is required that significant flags are set in the toolchainfile. However, CMake allows keeping such flags as a part of a compiler invocation command, but that is no longer the case after bitcoin#29233.

  1. CMake suggests dedicated CMAKE_CXX_FLAGS_INIT and CMAKE_CXX_FLAGS_<CONFIG>_INIT variable to deal with flags in a toolchain file.

So, this PR follows CMake philosophy and is compatible with the current set of use cases.

@@ -462,9 +492,27 @@ setup_split_debug_script()
add_maintenance_targets()
add_windows_deploy_target()


if(CMAKE_CROSSCOMPILING)

Choose a reason for hiding this comment

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

Just leaving a note that we should probably document this somehow. It was not clear to me that every depends build we do is considered a cross-compile (even if it isn't a cross compile).

Copy link
Owner Author

Choose a reason for hiding this comment

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

Addressed in #125.

@hebasto
Copy link
Owner Author

hebasto commented Mar 23, 2024

Rebased on top of the #123.

@hebasto
Copy link
Owner Author

hebasto commented Mar 24, 2024

There are a few way to justify this branch changes:

  • It works with OSS-Fuzz.

I've updated hebasto/oss-fuzz#3 for reviewers' convenience.

1. Use standard CMake's way to pass flags from depends to the main build
system using CMAKE_<LANGUAGE>_FLAGS_INIT variables instead of custom
DEPENDS_<LANGUAGE>_COMPILER_FLAGS ones. This guaranties using those
flags during various checks at the configuration stage.

2. Setting flags is decoupled from setting compilers in the toolchain
file.

3. Per-configuration flags are cached properly.

4. No longer needed to set -DCMAKE_BUILD_TYPE=None when building with
depends.

Fixes cross compilation for macOS.

Allows the user to use {C,CXX}FLAGS environment variables for depends
and the main build system without drawbacks/workarounds.
If any of {C,CXX,CPP,LD}FLAGS is specified it should be assigned to
a non-type-specific variable.
@hebasto
Copy link
Owner Author

hebasto commented Mar 25, 2024

My Guix builds:

x86_64
d4a9c172c32a8bcd2a4323dbcb99b08880deebf1b1f52a0cb0a53fe1a26ad2a1  guix-build-dbd2f7ad1e37/output/aarch64-linux-gnu/SHA256SUMS.part
cf05a836b2f0c23eeac7e6d428d6602574f86276dc45e15ca05f6bbd7e494406  guix-build-dbd2f7ad1e37/output/aarch64-linux-gnu/bitcoin-dbd2f7ad1e37-aarch64-linux-gnu-debug.tar.gz
137bd6dc122b07799ee15404ff29165bccd3841925d562fbb9feb747cae2b6d2  guix-build-dbd2f7ad1e37/output/aarch64-linux-gnu/bitcoin-dbd2f7ad1e37-aarch64-linux-gnu.tar.gz
bd6deba77b44acd21b0403426f093f97920927603654a31dde45f6b6bbad946b  guix-build-dbd2f7ad1e37/output/arm-linux-gnueabihf/SHA256SUMS.part
cd6b3a5f1abce83e94a35151e57f77e3cf92a959fa2b04df50192f877d12c89d  guix-build-dbd2f7ad1e37/output/arm-linux-gnueabihf/bitcoin-dbd2f7ad1e37-arm-linux-gnueabihf-debug.tar.gz
dc5b36b031f9ab1619db509135ef3cf53496a6a57a598d08d7463e5cf0bd42e1  guix-build-dbd2f7ad1e37/output/arm-linux-gnueabihf/bitcoin-dbd2f7ad1e37-arm-linux-gnueabihf.tar.gz
41f16f77ebd6290276e4e696f3490e2ee09dd8a9bf83dbcce2a102d11930df23  guix-build-dbd2f7ad1e37/output/dist-archive/bitcoin-dbd2f7ad1e37.tar.gz
c3140c2a1bb7f6b222dcc6340f7fd1692065580a66114f647dcb3f10558d2070  guix-build-dbd2f7ad1e37/output/powerpc64-linux-gnu/SHA256SUMS.part
fc169f3e09bca945e62463b39b7f2fde6a3ec5cc221f67acbcf163631e76997f  guix-build-dbd2f7ad1e37/output/powerpc64-linux-gnu/bitcoin-dbd2f7ad1e37-powerpc64-linux-gnu-debug.tar.gz
189cacfd5fc5c6b07f91d550e70517424d78a9ea2cf58e6309bf83fcd9be5ad4  guix-build-dbd2f7ad1e37/output/powerpc64-linux-gnu/bitcoin-dbd2f7ad1e37-powerpc64-linux-gnu.tar.gz
9e05b42cfa6a3e56eead23274ee8326c175f1fe8eae4db32bb7b32bedfe2a814  guix-build-dbd2f7ad1e37/output/powerpc64le-linux-gnu/SHA256SUMS.part
a983ce1d6d991fddb2fa0bb53b928b62d04e3f367720b46020259ac7a34efc8f  guix-build-dbd2f7ad1e37/output/powerpc64le-linux-gnu/bitcoin-dbd2f7ad1e37-powerpc64le-linux-gnu-debug.tar.gz
2d98a9b043bbffcecd3f9666f291d42737aa55174bb222859cbab6f4ae7eee0a  guix-build-dbd2f7ad1e37/output/powerpc64le-linux-gnu/bitcoin-dbd2f7ad1e37-powerpc64le-linux-gnu.tar.gz
6900097663ed888c933270c989a4b147a654176f687f42f08599a3d626afbf9a  guix-build-dbd2f7ad1e37/output/riscv64-linux-gnu/SHA256SUMS.part
ad5d8636371dc0f636cdea07d5b8fc5dbe4242432c2f27f67a767711b691f012  guix-build-dbd2f7ad1e37/output/riscv64-linux-gnu/bitcoin-dbd2f7ad1e37-riscv64-linux-gnu-debug.tar.gz
66a209f987df977e67cfb2944269310ddf65ce6660ddf37d941a43890fb6ba45  guix-build-dbd2f7ad1e37/output/riscv64-linux-gnu/bitcoin-dbd2f7ad1e37-riscv64-linux-gnu.tar.gz
6d8e8dfa0233d4b06f93beeaa3e0c887218f772d0c4c148aae288a40c5f77669  guix-build-dbd2f7ad1e37/output/x86_64-linux-gnu/SHA256SUMS.part
ffb01517da22aff9d132ab5286db5ccdb5e7393022c01e2215aeed536a850c2b  guix-build-dbd2f7ad1e37/output/x86_64-linux-gnu/bitcoin-dbd2f7ad1e37-x86_64-linux-gnu-debug.tar.gz
a4c7589706938a1d613459c725f193a4900f0ff8e1365a53be92004c70159ca0  guix-build-dbd2f7ad1e37/output/x86_64-linux-gnu/bitcoin-dbd2f7ad1e37-x86_64-linux-gnu.tar.gz
c4a34f93fc00addc54ed23c239c44e2f2cd124426042af0d98eb9061e0286fba  guix-build-dbd2f7ad1e37/output/x86_64-w64-mingw32/SHA256SUMS.part
4b842d19e5b1b9f8f622defd542349d367a4c421775d7b0e74befdad73b5997c  guix-build-dbd2f7ad1e37/output/x86_64-w64-mingw32/bitcoin-dbd2f7ad1e37-win64-debug.zip
e9d32a0b4f5207ac5da96cb56d8648c1ee39368db7f65924fc3750c66f82f2a2  guix-build-dbd2f7ad1e37/output/x86_64-w64-mingw32/bitcoin-dbd2f7ad1e37-win64-setup-unsigned.exe
e1d15de1bae8b1612c607bc7f1cc224fe61910dfe161f8bad40737925a5d9f18  guix-build-dbd2f7ad1e37/output/x86_64-w64-mingw32/bitcoin-dbd2f7ad1e37-win64-unsigned.tar.gz
4cce5684c70a6853fdc6214c588f1cc40d72d43693f4087295cda0dd9247bcb0  guix-build-dbd2f7ad1e37/output/x86_64-w64-mingw32/bitcoin-dbd2f7ad1e37-win64.zip

@TheCharlatan
Copy link

ACK, think we should move forward here.
Guix builds:

d4a9c172c32a8bcd2a4323dbcb99b08880deebf1b1f52a0cb0a53fe1a26ad2a1  guix-build-dbd2f7ad1e37/output/aarch64-linux-gnu/SHA256SUMS.part
cf05a836b2f0c23eeac7e6d428d6602574f86276dc45e15ca05f6bbd7e494406  guix-build-dbd2f7ad1e37/output/aarch64-linux-gnu/bitcoin-dbd2f7ad1e37-aarch64-linux-gnu-debug.tar.gz
137bd6dc122b07799ee15404ff29165bccd3841925d562fbb9feb747cae2b6d2  guix-build-dbd2f7ad1e37/output/aarch64-linux-gnu/bitcoin-dbd2f7ad1e37-aarch64-linux-gnu.tar.gz
bd6deba77b44acd21b0403426f093f97920927603654a31dde45f6b6bbad946b  guix-build-dbd2f7ad1e37/output/arm-linux-gnueabihf/SHA256SUMS.part
cd6b3a5f1abce83e94a35151e57f77e3cf92a959fa2b04df50192f877d12c89d  guix-build-dbd2f7ad1e37/output/arm-linux-gnueabihf/bitcoin-dbd2f7ad1e37-arm-linux-gnueabihf-debug.tar.gz
dc5b36b031f9ab1619db509135ef3cf53496a6a57a598d08d7463e5cf0bd42e1  guix-build-dbd2f7ad1e37/output/arm-linux-gnueabihf/bitcoin-dbd2f7ad1e37-arm-linux-gnueabihf.tar.gz
41f16f77ebd6290276e4e696f3490e2ee09dd8a9bf83dbcce2a102d11930df23  guix-build-dbd2f7ad1e37/output/dist-archive/bitcoin-dbd2f7ad1e37.tar.gz
c3140c2a1bb7f6b222dcc6340f7fd1692065580a66114f647dcb3f10558d2070  guix-build-dbd2f7ad1e37/output/powerpc64-linux-gnu/SHA256SUMS.part
fc169f3e09bca945e62463b39b7f2fde6a3ec5cc221f67acbcf163631e76997f  guix-build-dbd2f7ad1e37/output/powerpc64-linux-gnu/bitcoin-dbd2f7ad1e37-powerpc64-linux-gnu-debug.tar.gz
189cacfd5fc5c6b07f91d550e70517424d78a9ea2cf58e6309bf83fcd9be5ad4  guix-build-dbd2f7ad1e37/output/powerpc64-linux-gnu/bitcoin-dbd2f7ad1e37-powerpc64-linux-gnu.tar.gz
9e05b42cfa6a3e56eead23274ee8326c175f1fe8eae4db32bb7b32bedfe2a814  guix-build-dbd2f7ad1e37/output/powerpc64le-linux-gnu/SHA256SUMS.part
a983ce1d6d991fddb2fa0bb53b928b62d04e3f367720b46020259ac7a34efc8f  guix-build-dbd2f7ad1e37/output/powerpc64le-linux-gnu/bitcoin-dbd2f7ad1e37-powerpc64le-linux-gnu-debug.tar.gz
2d98a9b043bbffcecd3f9666f291d42737aa55174bb222859cbab6f4ae7eee0a  guix-build-dbd2f7ad1e37/output/powerpc64le-linux-gnu/bitcoin-dbd2f7ad1e37-powerpc64le-linux-gnu.tar.gz
6900097663ed888c933270c989a4b147a654176f687f42f08599a3d626afbf9a  guix-build-dbd2f7ad1e37/output/riscv64-linux-gnu/SHA256SUMS.part
ad5d8636371dc0f636cdea07d5b8fc5dbe4242432c2f27f67a767711b691f012  guix-build-dbd2f7ad1e37/output/riscv64-linux-gnu/bitcoin-dbd2f7ad1e37-riscv64-linux-gnu-debug.tar.gz
66a209f987df977e67cfb2944269310ddf65ce6660ddf37d941a43890fb6ba45  guix-build-dbd2f7ad1e37/output/riscv64-linux-gnu/bitcoin-dbd2f7ad1e37-riscv64-linux-gnu.tar.gz
6d8e8dfa0233d4b06f93beeaa3e0c887218f772d0c4c148aae288a40c5f77669  guix-build-dbd2f7ad1e37/output/x86_64-linux-gnu/SHA256SUMS.part
ffb01517da22aff9d132ab5286db5ccdb5e7393022c01e2215aeed536a850c2b  guix-build-dbd2f7ad1e37/output/x86_64-linux-gnu/bitcoin-dbd2f7ad1e37-x86_64-linux-gnu-debug.tar.gz
a4c7589706938a1d613459c725f193a4900f0ff8e1365a53be92004c70159ca0  guix-build-dbd2f7ad1e37/output/x86_64-linux-gnu/bitcoin-dbd2f7ad1e37-x86_64-linux-gnu.tar.gz
c4a34f93fc00addc54ed23c239c44e2f2cd124426042af0d98eb9061e0286fba  guix-build-dbd2f7ad1e37/output/x86_64-w64-mingw32/SHA256SUMS.part
4b842d19e5b1b9f8f622defd542349d367a4c421775d7b0e74befdad73b5997c  guix-build-dbd2f7ad1e37/output/x86_64-w64-mingw32/bitcoin-dbd2f7ad1e37-win64-debug.zip
e9d32a0b4f5207ac5da96cb56d8648c1ee39368db7f65924fc3750c66f82f2a2  guix-build-dbd2f7ad1e37/output/x86_64-w64-mingw32/bitcoin-dbd2f7ad1e37-win64-setup-unsigned.exe
e1d15de1bae8b1612c607bc7f1cc224fe61910dfe161f8bad40737925a5d9f18  guix-build-dbd2f7ad1e37/output/x86_64-w64-mingw32/bitcoin-dbd2f7ad1e37-win64-unsigned.tar.gz
4cce5684c70a6853fdc6214c588f1cc40d72d43693f4087295cda0dd9247bcb0  guix-build-dbd2f7ad1e37/output/x86_64-w64-mingw32/bitcoin-dbd2f7ad1e37-win64.zip

@hebasto hebasto merged commit ca22536 into cmake-staging Mar 25, 2024
27 checks passed
hebasto added a commit that referenced this pull request May 20, 2024
b231e61 depends: Add `CMAKE_SYSTEM_VERSION` to CMake toolchain file (Hennadii Stepanov)
6ff697a depends: Rename `cmake_system` > `cmake_system_name` (Hennadii Stepanov)
a856151 [FIXUP] cmake: Do not trigger cross-compiling unnecessarily (Hennadii Stepanov)

Pull request description:

  As it was [pointed](#82 (comment)) out during today's call, the toolchain file, which is generated by the depends build system, unnecessarily triggers CMake's [cross-compiling](https://cmake.org/cmake/help/latest/variable/CMAKE_CROSSCOMPILING.html) mode by setting the [`CMAKE_SYSTEM_NAME`](https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_NAME.html) variable even the host and build systems coincides.

  That behavior deviates from the current master branch and potentially might have unwanted/unexpected side effects.

  This PR fixes this issue.

  All Guix builds remain cross-compiling.

Top commit has no ACKs.

Tree-SHA512: a42d4b4dc2d0f0698d75255254876b6c16b12d5f3380cd647985e1650f9859a455d0aaf507fa6297e92c7330dfbf152045618759ccce49b804512bf1fc6713e9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants