8000 fix(build): Fix issue with cmake > 3.30 by fuhlig1 · Pull Request #1603 · FairRootGroup/FairRoot · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

fix(build): Fix issue with cmake > 3.30 8000 #1603

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 1 commit into
base: dev
Choose a base branch
from
Open

fix(build): Fix issue with cmake > 3.30 #1603

wants to merge 1 commit into from

Conversation

fuhlig1
Copy link
Member
@fuhlig1 fuhlig1 commented Mar 19, 2025

CMake 3.31 deprecates the compatibility with CMake < 3.10 which emits two warnings from Geant4 and vgm cmake macros. The usage of -Werror=dev turns the warning into an error which breaks the CI for some systems which already use cmake 3.31.

Checklist:

@fuhlig1
fix(build): Fix issue with cmake > 3.30
2dffb11 
CMake 3.31 deprecate Compatibility with CMake < 3.10 which emits two warnings
from Geant4 and vgm cmake macros. The usage of -Werror=dev turns the warning
into an error which breaks the CI for some systems which already use
cmake 3.31.
@coderabbitai coderabbitai
Copy link
coderabbitai bot commented Mar 19, 2025
📝 Walkthrough

Walkthrough

The change updates the build configuration in the FairRoot_build_test.cmake file by removing the "-Werror=dev" option from the list of build options. This modification prevents warnings from being treated as errors during the build process. All other options and the overall structure of the script remain unchanged. No adjustments were made to any public or exported entities.

Changes

File(s) Change Summary
FairRoot_build_test.cmake Removed the "-Werror=dev" option from the appended list of options, keeping the remaining build options unchanged.

Suggested reviewers

  • ChristianTackeGSI

Tip

⚡🧪 Multi-step agentic review comment chat (experimental)
  • We're introducing multi-step agentic chat in review comments. This experimental feature enhances review discussions with the CodeRabbit agentic chat by enabling advanced interactions, including the ability to create pull requests directly from comments.
    - To enable this feature, set early_access to true under in the settings.
📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d16b36a and 2dffb11.

📒 Files selected for processing (1)
  • FairRoot_build_test.cmake (0 hunks)
💤 Files with no reviewable changes (1)
  • FairRoot_build_test.cmake

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai or @coderabbitai title anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@dennisklein
Copy link
Member
dennisklein commented Mar 19, 2025 •
edited
Loading

Re-assigned to @ChristianTackeGSI as he added this option with the comment that this warning class should error in our CI. So, I guess, he has a solution - other than disabling the error - in mind for the case this is triggered.

@dennisklein
Copy link
Member

Perhaps related https://gitlab.kitware.com/cmake/cmake/-/issues/26288

@fuhlig1
Copy link
Member Author
fuhlig1 commented Mar 19, 2025

Re-assigned to @ChristianTackeGSI as he added this option with the comment that this warning class should error in our CI. So, I guess, he has a solution - other than disabling the error - in mind for the case this is triggered.

The problem is that the error doesn't come from our own project but from some of our dependencies which we can't fix.

@dennisklein
Copy link
Member

Re-assigned to @ChristianTackeGSI as he added this option with the comment that this warning class should error in our CI. So, I guess, he has a solution - other than disabling the error - in mind for the case this is triggered.

The problem is that the error doesn't come from our own project but from some of our dependencies which we can't fix.

Sure, but still interested what Christian had in mind in such cases. (I personally never understood how "warning:=error" type of flags shall work.)

Your PR proposes to remove the flag unconditionally, which means the original function - whatever it was supposed to be - goes away forever for all cases. Is this the intention? (In theory, you only need to disable it for cases where unsuitable Geant and VGM versions are used, right? Or better, if one could only apply it for local code)

@fuhlig1 fuhlig1 closed this Mar 19, 2025
@ChristianTackeGSI
Copy link
Member

The problem is that the error doesn't come from our own project but from some of our dependencies which we can't fix.

Sure, but still interested what Christian had in mind in such cases. (I personally never understood how "warning:=error" type of flags shall work.)

I naively had the hope that the option I had used would only affect our code (so that our code – which we can control – has no warnings at all).

As this flag also affects third party code, this hope has become a false one.

So, yes, please remove it from the general CI build.

Way forward:

  1. Maybe only enable it in the ubuntu-latest (it should have FairSoft-dev. So a fixed geant4 could be available soon there, maybe?). I am not really sure, that this is a Good Thing(TM) in the light of the new knowledge about this setting. Not really my recommendation. I've just put it here for completeness
  2. We're using "Warnings Next Generation" (I hope I am remembering correctly!) in our Jenkins CI. It filters the logs and adds metrics / etc for found warnings. It does not stop the build in any way. I think, it has support for CMake as well. So maybe we could enable that one? (I am not going to do that any time soon though.)

ChristianTackeGSI
ChristianTackeGSI approved these changes Mar 21, 2025
View reviewed changes
Copy link
Member
@ChristianTackeGSI ChristianTackeGSI left a comment

Choose a reason for hiding this comment

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

Possibly open a new Issue (so that we remember about it) about using warnings-next-generation in the CI instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ChristianTackeGSI ChristianTackeGSI ChristianTackeGSI approved these changes

@dennisklein dennisklein Awaiting requested review from dennisklein

Assignees

@ChristianTackeGSI ChristianTackeGSI

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@fuhlig1 @dennisklein @ChristianTackeGSI
0