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

Presets refactoring #255

Open
wants to merge 16 commits into
base: master
Choose a base branch
from
Open

Conversation

lceWolf
Copy link
Contributor

@lceWolf lceWolf commented Sep 20, 2024

This PR comes with an overhaul of the preset parsing / handling.
It contains the followin changes:

configure presets are now actual class instances with encapsulated data.

This is the enablement for the other features contained in the PR.

reduced access to disk

As the configure preset data is now encapsulated in the class instance, it is not necessary to read the preset file(s) multiple times to access different parts of the preset.
Previously, the most extreme case was determining the build_dir, which read the preset file for each inherited preset.
The new approach reads the file exactly once and parses the data into a hierarchy of preset instances.

presets from CMakePrests.json honored (#227)

If a CMakeUserPreset.json is found, the old implementation did not look up neither the inherited presets nor non-hidden presets from a CMakePreset.json file.
The new implementation reads both files and combines them into one data structure. The values from the CMakeUserPreset.json take precedence.

environment variable support

The new instance based approach allows building a environment table. This enables resolving environment variables ($env{<var>} and $penv{<var>}) for the environment table itself, but also other fields.
MacroExpansion (including envVars) currently supported for the binaryDir, condition variables and CacheVariables.

conditions

This PR adds support for conditions (except for matches and notMatches due to lua's regex capabilities).
If a preset is disabled via its condition, it is removed from the list of available configure presets and automatically deselected, if it is the currently selected configure preset.
If a configure preset and thereby the corresponding, currently selected build preset becomes available again, the configure preset is automatically selected again (based on the currently selected build preset).

Also included is a config option to hide any build preset which refers to a disabled configure preset. This is not standard cmake behaviour, but I think it is quite nice to be able to hide build preset's whose configure presets can not be used anyways.
Currently, this option is added to the base_settings and saved per session. This allows defining a default in the config, but re-configure it for inidividual projects, if needed.

misc

This PR prevents an error which occurs when cmake --target clean is issued if no cache is available. Now, the cache is only cleared, if it actually exists.

I moved the call to generate from BufWritePre to BufWritePost as this caused an error when a preset got disabled in the currently opened CMake[User]Preset.json file. generate would prompt the user to select another configure preset while the buffer is being written. This caused the preset selection to lose focus and become untargetable. Running generate after the buffer was written fixes this issue.

Denzel added 14 commits September 15, 2024 15:02
This commits enables parsing the Presets file even if a CMakeUserPreset
file was found.
That way it is possible to look up inherited presets from the
CMakePresets file when a CMakeUserPresets file is found
This prevents a "cache not available" error
This fixes an issue when the user has to select a configure preset while
generating the config.
If the generation is done at BufWritePre, the buffer is written while
the popup is still shown, which moves the cursor back to the now written
buffer. Selecting the popup to choose a preset is not possible anymore.

Writing the Buffer first and then prompting the user to select a
configure preset bypasses that issue
When a previously unavailable configure preset referenced by the current
build preset, we try to auto-select the configure preset and only ask
the user if there is still no configure preset available for the current
build preset
…reset

This is a pure personal take which is not default cmake beheviour.
When working with a CMake[User]Preset.json which contains lots of
configure and build presets, but only some of the configure presets are
active, having a huge list of buid presets, whose configurePreset is
disabled and can not be used, is a bit of a nuisance.
To help with that, with the newly added option these build presets can
be hidden from the selection list of available presets
@lceWolf lceWolf marked this pull request as draft September 20, 2024 20:16
Denzel added 2 commits September 22, 2024 13:17
just like conditions, these have to be parsed layer by layer. Building
these structures via recursion does not honor the inheritance order for
multiple inherits on a single preset
@lceWolf lceWolf marked this pull request as ready for review September 22, 2024 11:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant