Open N-Dekker opened 3 weeks ago
tensorstore
, this remote module's main dependency, is big and complicated, with a strange build system. Its CMake-based build system is auto-generated from Bazel, which is its source of truth. CMake being second-class citizen within tensorstore
has many strange side-effects. It has been long since I dealt with this, so I don't have any immediate suggestions.
For the record, I observed that a local ITKIOOMEZarrNGFF CMake configuration executes the "if(NOT ITK_SOURCE_DIR)" branch, while as remote module, the "else()" branch is executed, from https://github.com/InsightSoftwareConsortium/ITKIOOMEZarrNGFF/blob/ccf414fc599812e64df66e08efa0508c4a4c1d51/CMakeLists.txt#L14-L22
That does not explain why the remote module does not work, just a single baby step forward 😺
As an experiment, I tried to see if I could add a remote module to ITKIOOMEZarrNGFF, just by adding a file named "IOOMEZarrNGFF.remote.cmake" to ITK's source subdirectory "Modules\Remote", having:
At https://github.com/N-Dekker/ITK/tree/IOOMEZarrNGFF-remote
When I do a CMake Generate of my adjusted version of ITK, after having enabled the remote module, it says:
How could these errors possibly be avoided?
I guess the issue is related to the
target_link_libraries(IOOMEZarrNGFF PRIVATE tensorstore::tensorstore tensorstore::all_drivers)
call in https://github.com/InsightSoftwareConsortium/ITKIOOMEZarrNGFF/blob/6bb50d206670b2906558ebb47f77ad0e7306a7f0/src/CMakeLists.txt#L32Is there any workaround or possible fix?