You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since #529, mqt-core can finally be installed like a regular project.
However, the installation of all the main project libraries has bloated the binary Python wheels that we ship quite a bit. They went from a couple hundred KB to roughly 70MB. This isn't really great in the long run.
Describe the solution you'd like
A potential solution would be to go down a similar path as nanobind and ship the complete source code instead of the compiled targets.
Nanobind accomplished this by moving all the target creation code to the nanobind-config.cmake file and also installing the src folder in a predictable location so that the installation layout is the same as the source layout.
This would allow us to ship the source code with the Python package, but require the dependent package to build the respective targets.
For general installation of the C++ project, I believe it still makes sense to keep the targets install.
So my current proposal would be to make the current behavior the default and the proposed behavior opt-in (and automatically enabled for building the python package).
The text was updated successfully, but these errors were encountered:
What's the problem this feature will solve?
Since #529,
mqt-core
can finally be installed like a regular project.However, the installation of all the main project libraries has bloated the binary Python wheels that we ship quite a bit. They went from a couple hundred KB to roughly 70MB. This isn't really great in the long run.
Describe the solution you'd like
A potential solution would be to go down a similar path as
nanobind
and ship the complete source code instead of the compiled targets.Nanobind accomplished this by moving all the target creation code to the
nanobind-config.cmake
file and also installing thesrc
folder in a predictable location so that the installation layout is the same as the source layout.This would allow us to ship the source code with the Python package, but require the dependent package to build the respective targets.
For general installation of the C++ project, I believe it still makes sense to keep the targets install.
So my current proposal would be to make the current behavior the default and the proposed behavior opt-in (and automatically enabled for building the python package).
The text was updated successfully, but these errors were encountered: