Skip to content

🚸 Add support for CMake presets#363

Draft
denialhaag wants to merge 6 commits intomainfrom
cmake-presets
Draft

🚸 Add support for CMake presets#363
denialhaag wants to merge 6 commits intomainfrom
cmake-presets

Conversation

@denialhaag
Copy link
Copy Markdown
Member

Description

This PR adds support for CMake presets.

Fixes #352

Checklist

  • The pull request only contains commits that are focused and relevant to this change.
  • I have added appropriate tests that cover the new/changed functionality.
  • I have updated the documentation to reflect these changes.
  • I have added entries to the changelog for any noteworthy additions, changes, fixes, or removals.
  • I have added migration instructions to the upgrade guide (if needed).
  • The changes follow the project's style guidelines and introduce no new warnings.
  • The changes are fully tested and pass the CI checks.
  • I have reviewed my own code changes.

@denialhaag denialhaag self-assigned this Apr 23, 2026
@denialhaag denialhaag added c++ Anything related to C++ code feature New feature or request usability Anything related to usability labels Apr 23, 2026
Comment on lines +115 to +125
- name: Configure CMake with cmake-presets
if: ${{ inputs.use-cmake-presets }}
env:
PRESET_NAME: ${{ inputs.preset-name }}
SETUP_MLIR: ${{ inputs.setup-mlir }}
run: |
LIT_ARG=""
if [ "$SETUP_MLIR" = "true" ]; then
LIT_ARG="-DLLVM_EXTERNAL_LIT=$(which lit)"
fi
cmake --preset "$PRESET_NAME" -DENABLE_COVERAGE=ON "$LIT_ARG"
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

@burgholzer, I have two questions here:

  1. Do we want a coverage preset for this? I'm leaning toward no.
  2. Do we want to force -DCMAKE_BUILD_TYPE=Debug, or do we want to allow a user to pass the "wrong" config here?

Copy link
Copy Markdown
Member Author

@denialhaag denialhaag Apr 23, 2026

Choose a reason for hiding this comment

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

Another question: Do you see a better way of dealing with lit? We could get rid of the conditional statement above if we enforced the usage of something like LIT_PATH. We could export LIT_PATH=$(which lit) in our workflows, and the preset in FullStaQD/compiler would have to be adjusted to say "LLVM_EXTERNAL_LIT": "$env(LIT_PATH)" here: https://github.com/FullStaQD/compiler/blob/8ccc24fbe49595abe9c34a938c3d4ffa2cdaab94/CMakePresets.json#L12

We already have to say "MLIR_DIR": "$env(MLIR_DIR)" and "LLVM_DIR": "$env(LLVM_DIR)" if we do not want to start overwriting the default preset values. I feel like we are starting to miss the point of presets if we need to call cmake --preset dev -DMLIR_DIR=path/to/mlir/installation/dir -DLLVM_DIR=/path/to/llvm/installation/dir -DLLVM_EXTERNAL_LIT=$(which lit) to overwrite the defaults.

Comment on lines +183 to +187
- name: Generate compilation database with cmake-presets
if: ${{ inputs.use-cmake-presets }}
env:
PRESET_NAME: ${{ inputs.preset-name }}
run: cmake --preset "$PRESET_NAME"
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

@burgholzer, also here: Do we want to force -DCMAKE_BUILD_TYPE=Debug, or do we want to allow a user to pass the "wrong" config here?

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

Labels

c++ Anything related to C++ code feature New feature or request usability Anything related to usability

Projects

None yet

Development

Successfully merging this pull request may close these issues.

✨ Add support for CMake presets

1 participant