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

Ensure that the choice of compiler and target is passed to sub-projects. #17732

Merged
merged 1 commit into from
May 24, 2024

Conversation

Ferroin
Copy link
Member

@Ferroin Ferroin commented May 22, 2024

Summary

If not explicitly set using exported environment variables (or a toolchain file specified via the environment), the choice of compilers and compiler targets used by CMake does not get propagated to sub-porjects created with ExternalProject_Add or FetchContent_Declare in some situations.

In most cases this does not matter, because very few people are building using non-default compilers for their environment, but it can cause issues in two specific cases:

  • If building for the same system that the build is happening on, but using a non-default compiler specified using CMake arguments (instead of via exported environment variables), sub-projects will still use the default compiler for the system, which may result in linking errors (or runtime failures even if the link succeeds).
  • If cross-compiling and not using the preferred approaches of either a toolchain file or exported environment variables, sub-projects may not even build for the correct CPU architecture, causing the build to fail.

This adds logic to ensure that the compiler and compiler targets get propagated correctly even if they are just specified on the command line, thus avoiding the above two possibilities.

Test Plan

Primary testing involves ensuring that this builds correctly in CI.

Manual testing is required to ensure the propagation works correctly.

If not explicitly set using exported environment variables, the choice
of compilers and compiler targets used by CMake does not get propagated
to sub-porjects created with ExternalProject_Add or
FetchContent_Declare.

In most cases this does not matter, because very few people are building
using non-default compilers for their environment, but it can cause
issues in two specific cases:

- If building for the same system that the build is happening on, but
  using a non-default compiler specified using CMake arguments (instead
  of via exported environment variables), sub-projects will still use
  the default compiler for the system, which may result in linking
  errors (or runtime failures even if the link succeeds).
- If cross-compiling and not using the preferred approaches of either a
  toolchain file or exported environment variables, sub-projects may not
  even build for the correct CPU architecture, causing the build to
  fail.

This adds logic to ensure that the compiler and compiler targets get
propagated correctly even if they are just specified on the command
line, thus avoiding the above two possibilities.
@github-actions github-actions bot added area/packaging Packaging and operating systems support area/build Build system (autotools and cmake). labels May 22, 2024
@Ferroin Ferroin marked this pull request as ready for review May 22, 2024 15:16
@Ferroin Ferroin requested review from vkalintiris and a team as code owners May 22, 2024 15:16
@vkalintiris vkalintiris enabled auto-merge (squash) May 24, 2024 11:12
@vkalintiris vkalintiris disabled auto-merge May 24, 2024 11:12
@vkalintiris vkalintiris merged commit e81a8d8 into netdata:master May 24, 2024
148 of 149 checks passed
@Ferroin Ferroin deleted the fix-compiler-propagation branch May 28, 2024 16:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/build Build system (autotools and cmake). area/packaging Packaging and operating systems support
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants