Konrad Hofbauer wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Konrad Hofbauer wrote:
What helped for me is to add the following line to the top of
branch/development/cmake/CMakeLists.txt:
cmake_policy(SET CMP0005 NEW)
Could somebody please confirm that this is the right thing to do (and
does not brake older cmakes), and if so, commit it?
I will once Peter or Stefan confirm me that it's right. I guess it is.
I actually ended up with:
if(COMMAND cmake_policy)
cmake_policy(SET CMP0003 NEW)
cmake_policy(SET CMP0005 NEW)
endif(COMMAND cmake_policy)
which I think could go in.
cmake_policy changes the behavior of cmake to the NEW (2.6)
one or the OLD (2.4). If we wanna still support cmake 2.4,
checked by
cmake_minimum_required(VERSION 2.4)
then we should use the old behavior:
if(COMMAND cmake_policy)
cmake_policy(SET CMP0003 OLD)
cmake_policy(SET CMP0005 OLD)
endif(COMMAND cmake_policy)
Later on when we require cmake 2.6 we could drop these lines
and fix the cmake files.
I've checked in the "OLD" patch. Please check it on the Mac
with cmake 2.6.
If it works with cmake 2.4 but not with 2.6 then it is a
cmake bug, because for cmake 2.6 we've enabled 2.4 behavior.
Peter
But there are some more problems:
For the Mac, in
add_definitions(-DBOOST_USER_CONFIG="<config.h>")
the < > need to go, i.e. ...CONFIG=config.h)
And we end up with doubly defined symbols for VERSION_INFO, etc., since cmake
creates its own version.cpp (and linking fails in the end).
And, and, and ...
If somebody is willing to look at these things, I am happy to report more on
this & test. It is above my knowledge and time though to fix these things
properly.
Regards,
Konrad
--
Peter Kümmel
