Page MenuHomePhabricator

Pass down CMAKE_PREFIX_PATH to external projects
Closed, ResolvedPublic

Description

In our MITK-based project (NifTK) we build and install ITK, VTK and GDCM into separate folders, and accumulate the install directories to set the CMAKE_PREFIX_PATH. Then we want to make MITK pick up these projects from where we installed them.

It should be possible to pass down the CMAKE_PREFIX_PATH to the MITK superbuild, and MITK should pass it down to all of their external projects (EPs), including the MITK (MITK-Configure) subproject itself.

One problem is that if you pass a path (semicolon separated directory list) to an EP with the CMAKE_ARGS option, then only first element of the list is kept, the rest is lost. The way to get around this, is to replace the semicolons with another separator (e.g. double carets, '^^') and specify the 'LIST_SEPARATOR ^^' option for ExternalProject_Add.

Passing the path with the CMAKE_CACHE_ARGS option does not have this problem, you do not need to hack around with the separators. However, if you pass the path with CMAKE_CACHE_ARGS and then you reconfigure the project with a different path, the new value does not make it into the cache.

E.g. if we update VTK, and reconfigure MITK, the MITK cache will still have the prefix path to the old VTK install folder, not the new one.

Therefore the CMAKE_CACHE_ARGS must *never* be used to pass down options that are likely to change. (I would recommend not to use it at all.)

This commit solved the problem for me:

https://github.com/NifTK/MITK/commit/6e26ccb000fade75b08fdd939f292e83dabadeae

Event Timeline

The commit was based on 2014.10.0 but the current master has the same issue.

@Stefan Could you have a look at this? I think you already worked on passing down list variables correctly.

@Miklos Do you know it the current master still has the same issue?

Yes, the problems above are solved in the current master. We use indeed a solution based on CMAKE_CACHE_ARGS and CMAKE_CACHE_DEFAULT_ARGS and it works like a charm on our dartclients. Also the ProjectTemplate was adapted and is tested successfully again.