ENH: Add example project which used ITK Modules and FetchContent#5740
ENH: Add example project which used ITK Modules and FetchContent#5740dzenanz merged 1 commit intoInsightSoftwareConsortium:mainfrom
Conversation
github-actions
bot
added
type:Infrastructure
hjmjohnson
left a comment
hjmjohnson
left a comment
There was a problem hiding this comment.
@blowekamp This looks like a good example to have.
| include(FetchContent) | ||
|
|
||
| # Set ITK Git repository and tag | ||
| set(ITK_GIT_REPOSITORY "https://github.com/blowekamp/ITK.git") |
There was a problem hiding this comment.
@blowekamp This should probably default to InsightSoftwareConsortium rather than blowekamp organization.
There was a problem hiding this comment.
Yes, it is dependent PR #5721 for the modular interface libraries.
| # Set ITK Git repository and tag | ||
| set(ITK_GIT_REPOSITORY "https://github.com/blowekamp/ITK.git") | ||
|
|
||
| set(ITK_GIT_TAG "cmake_interface_module") |
There was a problem hiding this comment.
OK for DRAFT pr, but should this default to "main" or "v5.4.5" or "latest"? as the default?
There was a problem hiding this comment.
At least during development, it may be best to use a variable that points to the current git hash... This may get tricky with source distributions and keeping this directory independent of the ITK CMAkE environment.
So...likely "main" is the best option.
By use FetchContent for ITK, along with specific ITK module interface library linking enable to build only the targets needed in ITK for a project. While the initial configuration time is longer due to downloading and configuring ITK, the CMake project structure is simpler than a Superbuild, and the build is more efficient.
blowekamp
force-pushed
the
fetch_world
branch
from
65b38b2 to
f8c35f0
Compare
|
This is really a nice new way to build a project using ITK with the module interfaces. I'm not sure what the best ways to document and promote this. |
| add_executable(HelloFetchITK FetchWorld.cxx) | ||
|
|
||
| # If ITK was fetched and configure, only the required modules are built. | ||
| target_link_libraries(HelloFetchITK ITK::ITKCommonModule) |
There was a problem hiding this comment.
Seeing this here, I am now thinking that Module suffix is going to get repetitive quickly. Can you remind me why not use ITK::ITKCommon as the naming pattern? I guess that second ITK is needed to distinguish built-in modules vs. remotes (e.g. ITK::Montage).
There was a problem hiding this comment.
I encourage you to look at an ITKTargets.cmake file to see the library interfaces.
Let's ignore the namespace for now. ITKCommon references the compiled library. However, not every module has a library, and not every module that has a library is named the same as the module. And some modules have multiple libraries.
So the {itk-module}Module interface library refers to all the includes, libraries and dependecies of an ITK module. Even when a module does not have a library is still has the includes, and a list of other {itk-module}Modules that it depends on. For example a recent change was to use ITKZLIBModule for the zlib library. This may reference an imported ZLIB::ZLIB target or our third-party itkzlib library.
You can see more usage of the new ITK interface pattern in SimpleITK too: https://github.com/SimpleITK/SimpleITK/blob/main/Code/Common/CMakeLists.txt
4 participants
This is a standalone directly that can be build separately to try out this combination of feature to build a project/executable with ITK.
By use FetchContent for ITK, along with specific ITK module interface library linking enable to build only the targets needed in ITK for a project. While the initial configuration time is longer due to downloading and configuring ITK, the CMake project structure is simpler than a Superbuild, and the build is more efficient.
PR Checklist
Refer to the ITK Software Guide for
further development details if necessary.