Skip to content

Conversation

@fuhlig1
Copy link
Member

@fuhlig1 fuhlig1 commented Sep 29, 2025

The two commits allow to build and test FairRoot on macosx with a non default SDK. To use this feature a upcoming version of FairSoft is needed. Currently the head of jan24_patches which will soon get the tag jan24p6 or the release candidate branch for the upcoming new release sep25 will be okay.

For Linux systems or macosx systems using the default SDK the commits are not needed.

The two commits must be ported to the following branches:

  • v18.6_patches
  • v18.8_patches
  • v19.0_patches

Checklist:

@coderabbitai
Copy link

coderabbitai bot commented Sep 29, 2025

📝 Walkthrough

Walkthrough

Adds macOS SDKROOT handling to ROOT dictionary generation (CMake module and shell script) by deriving SDKROOT from CMAKE_OSX_SYSROOT and passing it to rootcling. Refactors test project scripts to build CMake parameters dynamically, optionally handle double-configure, and conditionally include CMAKE_OSX_SYSROOT.

Changes

Cohort / File(s) Summary of Changes
macOS SDKROOT propagation for ROOT dictionary
cmake/modules/FairRootTargetRootDictionary.cmake, cmake/scripts/generate_dictionary_root.sh.in
On Apple, derive SDKROOT from CMAKE_OSX_SYSROOT when set and pass it via environment to rootcling. Update env block to include both LD_LIBRARY_PATH and SDKROOT-related argument. Non-Apple behavior unchanged.
Parameterized CMake invocation in test templates
templates/test_project_root_containers.sh.in, templates/test_project_stl_containers.sh.in
Replace direct CMake calls with a parameters accumulator. Support optional double-configure by either running a second configure or setting -DUSE_DIFFERENT_COMPILER=true. Conditionally append -DCMAKE_OSX_SYSROOT when available. Invoke cmake $parameters .. once, then build and test as before. Adjust exports (CMAKE_PREFIX_PATH/SIMPATH) and control flow.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor Dev as Developer
  participant SH as generate_dictionary_root.sh
  participant CMake as CMake custom command
  participant Env as Environment
  participant RC as rootcling

  Dev->>CMake: Configure build (Apple or non-Apple)
  CMake->>SH: Invoke generate_dictionary_root.sh
  alt Apple with CMAKE_OSX_SYSROOT set
    SH->>Env: Export LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, SDKROOT
    Note right of SH: SDKROOT derived from CMAKE_OSX_SYSROOT
  else Other platforms / no sysroot
    SH->>Env: Export LD_LIBRARY_PATH, DYLD_LIBRARY_PATH
  end
  SH->>RC: Execute rootcling with env
  RC-->>SH: Generate dictionary
Loading
sequenceDiagram
  autonumber
  actor Dev as Developer
  participant TP as test_project_*_containers.sh
  participant CMake as CMake
  participant Build as make

  Dev->>TP: Run test script [args]
  TP->>TP: Initialize parameters (e.g., -DCMAKE_CXX_STANDARD)
  alt Double-configure flag
    TP->>TP: Set parameters and/or run second configure (root vs stl variants)
  else Single configure
    TP->>TP: Keep parameters as-is
  end
  opt macOS sysroot available
    TP->>TP: Append -DCMAKE_OSX_SYSROOT
  end
  TP->>CMake: cmake $parameters ..
  CMake-->>TP: Configure results
  TP->>Build: make -j
  Build-->>TP: Build output
  TP-->>Dev: Report success/failure
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Title Check ✅ Passed The title accurately summarizes the core change by stating that builds and tests on macOS are now supported with a non-default SDK, directly reflecting the pull request’s main functionality. It is concise, specific, and free of extraneous details, making it clear to reviewers and team members what the key update entails. The phrasing directly ties to the platform and feature introduced by the commits without unnecessary noise. Therefore, it meets the criteria for an effective pull request title.
Description Check ✅ Passed The provided description clearly outlines that the two commits enable building and testing on macOS with a non-default SDK and explains the required FairSoft versions and relevant backport branches. It directly relates to the changeset by distinguishing between default and non-default SDK scenarios and specifies the target branches for porting. This demonstrates that the description is on-topic and meaningfully tied to the pull request’s content. Hence, it satisfies the pull request description check.
Docstring Coverage ✅ Passed No functions found in the changes. Docstring coverage check skipped.
✨ Finishing touches
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Tip

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

  • Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
  • Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.


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

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 3

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3e17145 and b5bb9ad.

📒 Files selected for processing (4)
  • cmake/modules/FairRootTargetRootDictionary.cmake (1 hunks)
  • cmake/scripts/generate_dictionary_root.sh.in (1 hunks)
  • templates/test_project_root_containers.sh.in (1 hunks)
  • templates/test_project_stl_containers.sh.in (1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2024-06-14T10:16:00.050Z
Learnt from: dennisklein
PR: FairRootGroup/FairRoot#1560
File: cmake/private/FairRootConfig.cmake.in:13-13
Timestamp: 2024-06-14T10:16:00.050Z
Learning: `PACKAGE_PROJECT_CMAKEMOD_DIR` is defined by the call to `configure_package_config_file()` in the CMake configuration process for FairRoot.

Applied to files:

  • templates/test_project_stl_containers.sh.in

This change allows to build dictionaries with a non default macosx
software development package (SDK). This is needed to be able to
compile older ROOT versions on new compiler versions.
Pass the needed information about CMAKE_OSX_SYSROOT to rootcling
such that the template tests also work on macosx with a non standard
SDK.
@fuhlig1
Copy link
Member Author

fuhlig1 commented Oct 8, 2025

@dennisklein,

could you please have a look if the commits are okay from your side. I would like to merge them such that I can port them to the patches branches. My tests run nearly on all systems. The only problem still is the on ubuntu 24.04 where doing a 'cp -a' of the templates directory results in a crash of the tests but this problem is unrelated to the actual test performed.

@fuhlig1
Copy link
Member Author

fuhlig1 commented Oct 8, 2025

@dennisklein,

the same problem with cp -a to the /tmp directory is present for OpenSuse. cp -a to /scratch works on both systems. Looking more closely in the problem the preservation of the ownership is problematic.

So the problem is probably due to the handling of the /tmp directory from the container.

A possible workaround would be to use cp -dR which is equivalent to cp -a except of the explicit preservation of the permissions. Checking the files in the /tmp directory the timestamp, the access rights as well as the ownership look okay. For me it looks like that cp -dR does the permission preservation implicitly.

Replaces test_project_root_containers.sh.in and test_project_stl_containers.sh.in
with a single parameterized test_project.sh.in script to eliminate code duplication.
- Add proper argument parsing with case statement
- Use modern cmake -S/-B and --build syntax
- Replace backticks with $() syntax
- Add trap for cleanup on exit
- Use bash arrays for cmake parameters
- Add -u and -o pipefail to set flags
- Make -x conditional on DEBUG environment variable
- Add template directory validation
- Use readonly for immutable variables
- Redirect errors to stderr
- Add --help flag
@dennisklein
Copy link
Member

@dennisklein,

the same problem with cp -a to the /tmp directory is present for OpenSuse. cp -a to /scratch works on both systems. Looking more closely in the problem the preservation of the ownership is problematic.

So the problem is probably due to the handling of the /tmp directory from the container.

A possible workaround would be to use cp -dR which is equivalent to cp -a except of the explicit preservation of the permissions. Checking the files in the /tmp directory the timestamp, the access rights as well as the ownership look okay. For me it looks like that cp -dR does the permission preservation implicitly.

A simple cp -r will also do the job here, no? No objections on changing the cp parameters.

dennisklein
dennisklein previously approved these changes Oct 8, 2025
Copy link
Member

@dennisklein dennisklein left a comment

Choose a reason for hiding this comment

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

looks fine to me, I also did some deduplication/refactorings on the scripts, see fuhlig1/FairRoot@vdev_patches...dennisklein:FairRoot:vdev_patches

If you like them, feel free to fetch them :)

@dennisklein dennisklein requested a review from Copilot October 8, 2025 15:27
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR enables building and testing FairRoot on macOS with non-default SDKs by adding proper SDK path handling. The changes ensure that the CMAKE_OSX_SYSROOT variable is propagated to various build scripts and dictionary generation processes.

  • Added conditional CMAKE_OSX_SYSROOT parameter passing to test project build scripts
  • Updated dictionary generation to export SDKROOT environment variable when using non-default macOS SDKs
  • Modified CMake custom commands to include SDKROOT environment variable for rootcling execution

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File Description
templates/test_project_stl_containers.sh.in Added CMAKE_OSX_SYSROOT parameter handling and improved script structure
templates/test_project_root_containers.sh.in Added CMAKE_OSX_SYSROOT parameter handling and streamlined reconfigure logic
cmake/scripts/generate_dictionary_root.sh.in Added SDKROOT environment variable export for macOS SDK support
cmake/modules/FairRootTargetRootDictionary.cmake Added SDKROOT environment variable to custom command for rootcling execution

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

Using `cp -a` mode to the tmp directory from a container fails for
ubuntu 24.04 and opensuse 16.0 due failure of preserving permissions.
Using `cp -RP` will copy the directory recursivly not following any
symbolic links.
@fuhlig1
Copy link
Member Author

fuhlig1 commented Oct 9, 2025

looks fine to me, I also did some deduplication/refactorings on the scripts, see fuhlig1/FairRoot@vdev_patches...dennisklein:FairRoot:vdev_patches

If you like them, feel free to fetch them :)

Have you tested the changes? I had first a problem that the shell script for the template test wasn't executable which was easy to fix but now I run into problems that headers are not found during dictionary creation.

@dennisklein
Copy link
Member

Nope, had no fairsoft installation lying around.

@dennisklein
Copy link
Member

Compiling FairSoft now and going to test the script changes

@fuhlig1
Copy link
Member Author

fuhlig1 commented Oct 9, 2025

I found the first issue but at least for v18.6_patches I wonder how the compilation could have worked before.

@dennisklein
Copy link
Member

Tested FairRoot (this PR branch) + FairSoft jan24p5 installed in /cvmfs/fairsoft_dev.gsi.de/ci/for-fairsoft/latest/container/ubuntu.22.04.legacy.sif. Besides the missing execution bit, this worked (Note: I built and installed FairRoot before running the tests):

Singularity> ctest --test-dir build -R container --output-on-failure -j16
Internal ctest changing into directory: /home/dklein/projects/FairSoft/FairRoot/build
Test project /home/dklein/projects/FairSoft/FairRoot/build
    Start 5: project_stl_containers_double
    Start 3: project_root_containers_double
    Start 4: project_stl_containers
    Start 2: project_root_containers
1/4 Test #2: project_root_containers ..........   Passed   25.90 sec
2/4 Test #4: project_stl_containers ...........   Passed   25.91 sec
3/4 Test #5: project_stl_containers_double ....   Passed   26.17 sec
4/4 Test #3: project_root_containers_double ...   Passed   26.28 sec

100% tests passed, 0 tests failed out of 4

Total Test time (real) =  26.28 sec

Also ran the full test suite

100% tests passed, 0 tests failed out of 68

Total Test time (real) =  39.08 sec

Let me know, if I can help with any different environment.

Shell script must be executable.
@fuhlig1
Copy link
Member Author

fuhlig1 commented Oct 9, 2025

Ok. I don't understand why it worked in your case but at least in the debian13 container the execution of the generated script test_project.sh haven't worked. It simply had no execution rights. After I changed that the tests for this branch, the v19.0_patches and the v18.8_patches branches worked like expected.
Unfortunately I started with the v18.6_patches branch and there beside the problem with the execution rights there were some errors in the build system as well as the code. This couldn't have worked before but when running the FairSoft test suite the test for v18.6_patches always worked.
I will do the tests again and if everything now works I will merge.

@dennisklein
Copy link
Member

It simply had no execution rights.

Yes, this was missing, as I acknowledged in my post ;)

@fuhlig1 fuhlig1 requested a review from dennisklein October 10, 2025 13:21
@dennisklein dennisklein requested a review from Copilot October 10, 2025 13:58
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.


Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

@dennisklein dennisklein merged commit e22c961 into FairRootGroup:dev Oct 10, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants