Stealing CMake-magic from KDE4 for Apple

Moin

Only Geoff can test all this I guess… I had a look at how KDE4
handles platform specific compilation stuff. Here is what kdelibs does
for the Apple-platform… I am not sure if or if not we just sync our
CMake-magic with the KDE4-cmake stuff…

Also, currently we depend on CMake 2.4.3 while KDE is depending on
2.4.5 for about 3 or 4 month already. 2.4.6 was released some month
ago, 2.4.7 last week. Perhaps we should also depend on 2.4.5 because
if we don’t do that it might happen that we cannot use KDEs CMake-code
as they are using 2.4.5 features quite a lot…

Opinions?

Carsten

This will need to be modified later to support either Qt/X11 or Qt/Mac builds

if (APPLE)

set ( KDE4_PLATFORM_DEFINITIONS -D__APPLE_KDE_ )

we need to set MACOSX_DEPLOYMENT_TARGET to (I believe) at least

10.2 or maybe 10.3 to allow

-undefined dynamic_lookup; in the future we should do this programmatically

hmm… why doesn’t this work?

set (ENV{MACOSX_DEPLOYMENT_TARGET} 10.3)

“-undefined dynamic_lookup” means we don’t care about missing

symbols at link-time by default

this is bad, but unavoidable until there is the equivalent of

libtool -no-undefined implemented

or perhaps it already is, and I just don’t know where to look :wink:

set (CMAKE_SHARED_LINKER_FLAGS “-single_module -multiply_defined
suppress {CMAKE_SHARED_LINKER_FLAGS}") set (CMAKE_MODULE_LINKER_FLAGS "-multiply_defined suppress {CMAKE_MODULE_LINKER_FLAGS}”)
#set(CMAKE_SHARED_LINKER_FLAGS “-single_module -undefined
dynamic_lookup -multiply_defined suppress”)
#set(CMAKE_MODULE_LINKER_FLAGS “-undefined dynamic_lookup
-multiply_defined suppress”)

we profile…

if(CMAKE_BUILD_TYPE_TOLOWER MATCHES profile)
set (CMAKE_SHARED_LINKER_FLAGS “{CMAKE_SHARED_LINKER_FLAGS} -fprofile-arcs -ftest-coverage") set (CMAKE_MODULE_LINKER_FLAGS "{CMAKE_MODULE_LINKER_FLAGS}
-fprofile-arcs -ftest-coverage”)
endif(CMAKE_BUILD_TYPE_TOLOWER MATCHES profile)

removed -Os, was there a special reason for using -Os instead of -O2 ?, Alex

optimization flags are set below for the various build types

set (CMAKE_C_FLAGS “{CMAKE_C_FLAGS} -fno-common") set (CMAKE_CXX_FLAGS "{CMAKE_CXX_FLAGS} -fno-common”)
endif (APPLE)

also use /usr/local by default under UNIX, including Mac OS X

if (UNIX)
option(KDE4_USE_ALWAYS_FULL_RPATH “If set to TRUE, also libs and
plugins will be linked with the full RPATH, which will usually make
them work better, but make install will take longer.” OFF)

link_directories(/usr/local/lib)
set( _KDE4_PLATFORM_INCLUDE_DIRS /usr/local/include )

the rest is RPATH handling

here the defaults are set

which are partly overwritten in kde4_handle_rpath_for_library()

and kde4_handle_rpath_for_executable(), both located in

KDE4Macros.cmake, Alex
if (APPLE)
set(CMAKE_INSTALL_NAME_DIR {LIB_INSTALL_DIR}) else (APPLE) # add our LIB_INSTALL_DIR to the RPATH and use the RPATH figured out by cmake when compiling set(CMAKE_INSTALL_RPATH {LIB_INSTALL_DIR} )
set(CMAKE_SKIP_BUILD_RPATH TRUE)
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
endif (APPLE)
endif (UNIX)

Am Samstag, 21. Juli 2007 14:12:47 schrieb Carsten Niehaus:

Also, currently we depend on CMake 2.4.3 while KDE is depending on
2.4.5 for about 3 or 4 month already. 2.4.6 was released some month
ago, 2.4.7 last week. Perhaps we should also depend on 2.4.5 because
if we don’t do that it might happen that we cannot use KDEs CMake-code
as they are using 2.4.5 features quite a lot…

Done (yesterday).

Carsten