SlicerJupyter use-case custom application bundling use-case
There is no need to specify additional set(${proj}_DEPENDS ..)
To make things concrete, bundling SlicerJupyter
would only require the following in the custom application top-level CMakeLists.txt
:
# SlicerJupyter
set(extension_name "SlicerJupyter")
set(${extension_name}_SOURCE_DIR "${CMAKE_BINARY_DIR}/${extension_name}")
FetchContent_Populate(${extension_name}
SOURCE_DIR ${${extension_name}_SOURCE_DIR}
GIT_REPOSITORY ${EP_GIT_PROTOCOL}://github.com/Slicer/SlicerJupyter.git
GIT_TAG b282a2c819da1e3e4fe1ab6c419e2299f976720d
GIT_PROGRESS 1
QUIET
)
list(APPEND Slicer_EXTENSION_SOURCE_DIRS ${${extension_name}_SOURCE_DIR})
ExternalProject_Add_Dependencies(pybind11
DEPENDS
python
)
ExternalProject_Add_Dependencies(python-packages
DEPENDS
python
python-pip
python-setuptools
)
The configuration output effectively indicates the dependencies are considered:
$ cmake -DCMAKE_BUILD_TYPE:STRING=Release -DQt5_DIR:PATH=$Qt5_DIR ../SlicerGalaxy
[...]
-- SuperBuild - python-packages => Requires python[INCLUDED], python-pip[INCLUDED], python-setuptools[INCLUDED],
-- SuperBuild - python-packages[OK]
[...]
-- SuperBuild - pybind11 => Requires python[INCLUDED],
-- SuperBuild - pybind11[OK]
[...]
Suggested SlicerJupyter updates
-
There are some hard-coded instance of the string
lib/python3.6/site-packages
that should be removed. Instead the variablePYTHON_SITE_PACKAGES_SUBDIR
should be used. This pull request should take care of this: COMP: Fix python-packages external project removing hard-coded site-packages path by jcfr · Pull Request #67 · Slicer/SlicerJupyter · GitHub -
Considering
python-packages
project name is fairly generic and could conflict with other extension install python packages, we should rename it topython-slicerjupyter-requirements
. This will be done after the previous pull-request has been integrated. It is tracked by this issue: Rename `python-packages` external project to `python-slicerjupyter-requirements` · Issue #68 · Slicer/SlicerJupyter · GitHub -
To provide some more flexibility, we should also look into adding
Slicer_REQUIRED_PYTHON_VERSION_DOT
recently introduced in Slicer@e32fa814f toSlicerConfig.cmake.in
. This pull request takes care of this: COMP: Add Slicer_REQUIRED_PYTHON_VERSION_* variables to SlicerConfig by jcfr · Pull Request #6169 · Slicer/Slicer · GitHub