-
-
Notifications
You must be signed in to change notification settings - Fork 73
π§ Harden installed QDMI runtime staging #2231
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
Draft
burgholzer
wants to merge
1
commit into
codex/qdmi-default-driver-extension-c2
from
codex/qdmi-installed-consumer-deployment-c3
Draft
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,40 @@ | ||
| # Installed QDMI runtime deployment | ||
|
|
||
| Status: independently rebased and locally validated; hosted Windows CI pending. | ||
|
|
||
| ## Motivation and scope | ||
|
|
||
| Installed CMake consumers need the same complete runtime layout as in-tree | ||
| applications. The existing mqt_copy_qdmi_runtime helper must stage imported | ||
| Client, driver, device libraries, manifests, provider assets and Windows DLLs. | ||
|
|
||
| This is Core PR #2231 on #2230, targeting Core 4.1 / QDMI 1.4. It does not | ||
| depend on metadata removal, batching, or payload capabilities. No payload-format | ||
| header is introduced by the driver workstream. | ||
|
|
||
| ## Decisions | ||
|
|
||
| Reuse the existing imported-device fixture as a real find_package consumer. Use | ||
| copy_if_different for local and imported runtime targets. Imported targets must | ||
| not become build dependencies. For Windows, retain the non-imported | ||
| linker-language-bearing closure used to compute transitive imported DLLs. | ||
| Preserve device metadata and asset copying, and use the build RPATH while | ||
| running staged build-tree applications. | ||
|
|
||
| This changes deployment only. It does not add Client APIs, providers, compiler | ||
| behavior, or a second package-consumer harness. | ||
|
|
||
| ## Validation | ||
|
|
||
| Run the release build, both imported-device fixture tests, and the full native | ||
| suite. The fixture must resolve installed Core targets, execute the consumer, | ||
| and compare staged libraries, manifest, assets and Windows dependency files. | ||
| Check that the helper disables BUILD_WITH_INSTALL_RPATH on its consumer. Run | ||
| repository lint; Windows hosted CI remains necessary for real DLL loading. | ||
|
|
||
| The release build and native suite pass: 3,873 tests pass and one existing | ||
| optional-device test skips. Both installed-consumer fixture tests pass. | ||
|
|
||
| Keep useful commits, human attribution and existing review threads. Do not | ||
| create archive branches or request reviews. Published artifacts require released | ||
| dependency pins. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This definitely goes out of its way to prove that something works. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels overly complicated and slightly confusing, especially because of the terminology being used. "closure", "staging", "concrete", "runtime".
I think this is important work to ensure a robust installation and usage; but it needs to be prepared in a better fashion.
Our top distribution channel is the
mqt-corePython package. It is either directly used, which needs to work with the shipped libraries. Or it is loaded in other Python-only libraries (also not critical), or it is used to feed afind_package(mqt-core)call in another project (such as MQT QCEC, MQT DDSIM, or MQT QMAP). The latter case is probably the one that is hardest to get right across all systems when it comes to using the QDMI-related functionality.However, I still have the feeling that most of that was already working quite alright.
The second distribution channel is likely installations in HPC centers. These would typically build MQT Core from source via tools like
spack. I do not really foresee major problems there with the solution that we previously had in place (maybe I am missing something though). The key aspect here is that this is almost exclusively for Linux (x86 and arm64), while the Python distribution channel is much broader and needs to cover macOS and Windows.Maybe one can simplify around that information and already include these thoughts in the iteration on the lower layers.