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
ENH: Add option to disable python wrapping on loadable modules #6895
base: main
Are you sure you want to change the base?
ENH: Add option to disable python wrapping on loadable modules #6895
Conversation
This makes the python wrapping for loadable module components depend on the `Slicer_USE_PYTHONQT` CMake variable
Generally speaking, fixing this makes sense. Instead of adding code in each module (and extension), I suggest to instead update the Slicer CMake macros to skip wrapping if the option |
That makes sense. I can work on it. |
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This introduces `Slicer_USE_PYTHONQT` as a variable to consider for python wrapping in `Base` and `Libs` components. This should probably be merged with the developments on Slicer#6895 and with the modernization of the python detection in earlier Systole patches
This makes the python wrapping for loadable module components depend on the
Slicer_USE_PYTHONQT
CMake variable. This avoids python wrapping whenSlicer_USE_PYTHONQT=OFF
, which can save generation of files that won't be used.NOTE: For discussion purposes, so far, this PR applies the concept only to the MRML components of the Colors module, but the idea would be to apply this across modules and components. Alternatively, the
Slicer_USE_PYTHONQT
variable could be checked on the CMake SlicerBuild macros.@pieper, @jcfr would these changes make sense to you?