Fix linter

[ystade]

Description

This PR fixes an issue that was only discovered in #982 in MQT Core. Before, pybind11 was installed in a different python environment than later used during the run of cpp-linter. Now, we use the same env.

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.

[burgholzer]

What. This is something to look into further.
What you are doing here is exactly what the setup-uv option should accomplish.

Besides that, this PR contains some extra commits from the other branch apparently.

[ystade]

Oops, sorry. The other commits should not have been part of this PR here. They are removed now.

The issue is, that the cpp-linter sets up its own virtual environment venv and activates it. Hence, during linting it cannot find the pybind11 headers anymore. Setting up an virtual environment with the same name via uv and installing pybind11 there hopefully resolves the issue.

[ystade]

The issue is that one apparently can neither tell cpp-linter to use the existing venv nor to tell uv-setup how the virtual environment should be called.

[burgholzer]

Oops, sorry. The other commits should not have been part of this PR here. They are removed now.

The issue is, that the cpp-linter sets up its own virtual environment venv and activates it. Hence, during linting it cannot find the pybind11 headers anymore. Setting up an virtual environment with the same name via uv and installing pybind11 there hopefully resolves the issue.

Ah. That makes more sense now.
Seems like a bit of an ugly workaround (depending on internals of the cpp-linter), but if it works, that's great.
Could we add some of the above in some form as an in-code comment so that we do not forget why this is there? Then, this is good to go.

[ystade]

Ok, this PR became superfluous. The workflow works just fine, there is no bug in the workflow. THe issue in the other PRs using this workflow were caused by a typo, i.e., -DBUILD_MQT_QMAP_BINDINGS=ON instead of -DBUILD_MQT_CORE_BINDINGS=ON (mind the QMAP and CORE).