[Insight-users] CMake Error with Insight as child project

[Kent Williams]

I'm having trouble even determining which mailing list this should go to 
-- insight-developers? insight-users? cmake-users?

I'm going to try it here on insight-users first.

I am trying to build a number of packages all at once, controlled by a 
toplevel CMakeLists.txt.

In other words I have a directory tree like this

src/
    Insight
    CableSwig
    VTK
    InsightApplications
    WrapITK
    SOViewer
    KWWidgets

The top level directory (src) has this CMakeLists.txt file:

PROJECT(ITKVTKKWW)
ADD_SUBDIRECTORY(Insight )
ADD_SUBDIRECTORY(CableSwig )
ADD_SUBDIRECTORY(VTK )
ADD_SUBDIRECTORY(InsightApplications )
ADD_SUBDIRECTORY(WrapITK )
ADD_SUBDIRECTORY(SOViewer )
ADD_SUBDIRECTORY(KWWidgets )
 
The problem is that Insight has a problem in one of its macros, which 
generates the following errors:

 CMake Error: File 
/scratch/kent/KWW/src/CMake/CheckCPPDirectiveExists.cxx.in does not exist.
 CMake Error: Error in cmake code at  
/scratch/kent/KWW/src/Insight/CMake/CheckCPPDirective.cmake:11:  
CONFIGURE_FILE Problem configuring file
 CMake Error: Error in cmake code at  
/scratch/kent/KWW/src/Insight/CMakeLists.txt:470: A command failed 
during the invocation of macro "CHECK_CPP_DIRECTIVE_EXISTS".
 CMake Error: Error in cmake code at  
/scratch/kent/KWW/src/Insight/CMakeLists.txt:470:  
CHECK_CPP_DIRECTIVE_EXISTS unknown error.
 The end of a CMakeLists file was reached with an IF statement that was 
not  closed properly.
 Within the directory: /scratch/kent/KWW/src/Insight

Now I understand (roughly) what the problem is. The 
CHECK_CPP_DIRECTIVE_EXIST Macro uses a helper file 
CheckCPPDirectiveExists.cxx.in, which is in Insight/CMake.  If you 
configure Insight by itself, it can find this file relative to 
${CMAKE_SOURCE_DIR}, because that will resolve to the Insight source tree.
But if, as I have done, you want to get Insight built as part of a large 
project, you lose;  ${CMAKE_SOURCE_DIR} is the parent directory -- in my 
case src.

Does this mean you _MUST ALWAYS_ configure, build and install Insight by 
itself? This seems kind of counterproductive for a couple of reasons:

1. If you can plug Insight into a larger project, you can encapsulate 
the configuration information to produce compatible versions of 
different compenent libraries.
2. It doesn't seem a large price to pay to make Insight buildable in 
more than one context.