[CMake] Bump -- CMAKE_INSTALL_PREFIX weirdness.

[Bill Hoffman]

Alan W. Irwin wrote:
> On 2008-05-22 16:36-0500 kent williams wrote:
> 
>> I'll ask this again.
>>
>> We use a build system that for better or worse, invokes cmake from a
>> Makefile to configure ITK, VTK, KWWidgets etc.
>>
>> In other words we have a command invoked from gnu make that looks like 
>> this:
>> cmake  /scratch/kent/brains2/iplFreeware/unpackdir/Insight
>> -DCMAKE_INSTALL_PREFIX:PATH=/scratch/kent/brains2/MACOSX/DEBUG/src \
>> -DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_BUILD_TYPE:STRING=Debug
>> -DCMAKE_CXX_COMPILER:FILEPATH="c++ " \
>> -DCMAKE_CXX_FLAGS:STRING=" -bind_at_load  -g -UNDEBUG -Wall
>> -Wcast-qual -UITKIO_DEPRECATED_METADATA_ORIENTATION "
>> -DCMAKE_CXX_FLAGS_RELEASE:STRING=" -bind_at_load  -g -UNDEBUG -Wall
>> -Wcast-qual -UITKIO_DEPRECATED_METADATA_ORIENTATION "
>> -DCMAKE_CXX_FLAGS_DEBUG:STRING=" -bind_at_load  -g -UNDEBUG -Wall
>> -Wcast-qual -UITKIO_DEPRECATED_METADATA_ORIENTATION "
>>
>> etc etc etc.
> 
> The two things I notice with the above are (a) you use an absolute path to
> point to your top-level source tree (which I think is OK, but I don't use
> that), and (b) your path-to-source is out of order.  It should be the last
> part of the command according to my experience and also the cmake man page.
> 
> I would suggest putting your -D options first, then the path to your source
> tree (absolute or relative) to see whether that solves your issue.  I am
> actually surprised the -D options were even recognized part of the time 
> with
> them being placed incorrectly after the path.
> 

Also, what version of CMake are we talking about here?  There were bugs 
in some versions of CMake with the -D and the cache.  Perhaps it works 
when you use the right versions of CMake.

-Bill