CMake says TBB version incompatible with ITK installed via conda/mamba

Beginner Questions
1

Hi

I installed ITK on a Windows 10 machine via

mamba create -n pvc install petpvc libitk-devel

(petpvc requires libitk). I then used (non-Conda) CMake 3.25.2 (and VS 2022) to try and build PETPVC sources. After setting ITK_DIR I get

CMake Error at C:/Users/xxx/miniconda3/envs/pvc/Library/lib/cmake/ITK-5.3/Modules/ITKBBB.cmake:15 (find_package)
Could not find a configuration file for package "TBB" that is compatible with requestion version "".

The following configuration files were considered but not accepted:
C:/Users/xxx/miniconda3/envs/pvc/Library/lib/cmake/TBB/TBBConfig.cmake, version: 2021.8.0 (64bit)

Call stack (most recent calls first):
  C:/Users/xxx/miniconda3/envs/pvc/Library/lib/cmake/ITK-5.3/ITKModuleAPI.cmake (76) include)
   <snip>

I’ve seen this type of (in my opinion confusing) CMake message about incompatible versions before but then it normally is followed by a missing library/component or whatever, but here I had no further diagnostics.

I’ve tried to reproduce this on a different Windows 10 machine (using same CMake, same mamba command etc), (I have only restricted access to the previous one), but there it works fine…

Checking the content of .../ITK-5.3/Modules/ITKTBB.cmake on the second machine it contains

set(TBB_DIR "C:/Users/krisf/miniconda3/envs/petpvc/Library/lib/cmake/TBB")
find_package(TBB REQUIRED CONFIG)

so indeed it doesn’t ask for a version so all looks fine.

Any ideas?

2

Good morning,

This is related to the libitk-feedstock in Conda forge.

Is the “tbb-devel” Conda package installed?

3

Hi, yes, it might be related to the feedstock, but I’m not sure, given the confusing message and the fact the conda package works on another windows pc.

Sorry to be incomplete, yes, the tbb-devel is installed (v 2021.8.0). I guess that supplied .../lib/cmake/TBB/TBBConfig.cmake that CMake found (but rejected for unclear reasons).

I will get access to the other PC in the next few days again, but if anyone has any suggestions on what I could try, that’d help.

4

For building libsimpleitk recipe in conda forge this: ’ -D “CMAKE_FIND_ROOT_PATH:PATH=${PREFIX}” ’ CMake argument was required before it was moved to the CMAKE_ARGS variable in the recipe build scripts. Perhaps some of these CMake variable are important for configuring your project to use condo forge packages: Use CMAKE_ARGS is build.sh · conda-forge/libsimpleitk-feedstock@aaf9da6 · GitHub

5

thanks @blowekamp . Unfortunately, I cannot see how this is going to help. The CMAKE_FIND_ROOT_PATH would be necessary if CMake didn’t find TBB at all, but it did find the relevant file, it just wasn’t happy with it…

But I’ll give it a go when I have access.

6

sorry for the delay. Adding CMAKE_FIND_ROOT_PATH did not help.

This is all quite weird. I checked the content of C:/Users/xxx/miniconda3/envs/pvc/Library/lib/cmake/TBB/TBBConfig.cmake, and it contains

include(${CMAKE_CURRENT_LIST_DIR}/TBBTargets.cmake)

(as expected). I put a message(STATUS "I am here") in front of the include, and it doesn’t appear. (Putting a message in ITKTBB.cmake before the find_package does work).
So, find_package is rejecting the file without actually parsing it.

Amazingly, saving TBBConfig.cmake as TBB2Config.cmake and modifying ITKTBB.cmake to do find_package(TBB2 ...) means that the file is read. I then get an identical message on hdf5-config.cmake though.

I have no idea why this is happening… (nor any idea how to debug it. cmake --debug-find doesn’t show up anything helpful to diagnose this as far as I can see). Maybe it’s some strange file permission problem (although can read/write the file with wordpad for instance).

Oh well.

7

CMake debugger is currently in VS preview, but worth trying. I have not tried this myself - waiting for it to come to a stable version.

8

That looks like a great addition, thanks for that pointer! However, I don’t think this will help in this case. Putting in my manual print statements shows that the call to find_package returned without getting into the relevant CMake file (while it did find it). I doubt that the debugger will step “into” find_package