[CMake] Xcode generator problems

[Axel Roebel]

Hello William,

god news that there is a new version. I tried it instantly.
My first impression was not so positive
I found that it takes ages for the dependency checking.
I am working with template libraries where most of the code
is in include files. May be it is due to that, but with cmake 
2.2.3 dependency checking was nevertheless 10 times faster.
With 2.4.1 dependency checking  takes longer than
compiling the project.

Cheers,

Axel
On Monday 01 May 2006 23:05, William A. Hoffman wrote:
> At 03:12 PM 5/1/2006, Axel Roebel wrote:
> >Hi,
> >
> >I just tried to generate Xcode project files for some of my
> >cmake supported sources. I encountered three problems:
> >
> >1)  I tried to communicate -framework Carbon flags
> >to the link stage. I tried
> >
> >SET(LINK_FRAMEWORKS "-framework Accelerate -framework Carbon")
> >
> >   SET(CMAKE_SHARED_LINKER_FLAGS_RELEASE
> > "${CMAKE_SHARED_LINKER_FLAGS_RELEASE} ${LINK_FRAMEWORKS} " CACHE STRING
> > "Linker flags " FORCE)
> >  SET(CMAKE_SHARED_LINKER_FLAGS_RELEASE
> > "${CMAKE_SHARED_LINKER_FLAGS_RELEASE} ${LINK_FRAMEWORKS} " CACHE STRING
> > "Linker flags " FORCE)
> >
> >as well as
> >
> > SET_TARGET_PROPERTIES(svpmain${DEBUGEXT} PROPERTIES LINKER_LANGUAGE CXX
> >OUTPUT_NAME svp  LINK_FLAGS ${LINK_FRAMEWORKS})
> >
> >In both cases the generated project does not use the framework flags I
> > asked for. The unix makefile generator, however, works properly. Maybe
> > there is a reason or another mechanism that should be used?
>
> -framework should be treated just like linking a library.
> TARGET_LINK_LIBRARIES(foo -framework Bar)
> In addition, for 2.4.1, if you give the full path to a framework,
> CMake will automatically add the correct -F -framework flags.
>
> >The second problem is more annoying:
> >
> > From time to time the compiler fails completely and the error.log shows
> > the error message:
> >...
> >   setenv VERSION_INFO_STRING "\"@(#)PROGRAM:XCODE_DEPEND_HELPER 
> > PROJECT:CMAK E_TRY_COMPILE-  DEVELOPER:roebel  BUILT:\" __DATE__  \" \"
> > __TIME__ \"\"" setenv WARNING_CFLAGS "-Wmost -Wno-four-char-constants
> >-Wno-unknown-pragmas
> >"
> >    setenv XCODE_APP_SUPPORT_DIR "/Library/Application
> > Support/Apple/Developer Tools"
> >    setenv YACC /usr/bin/yacc
> >    /bin/sh
> >-c /Users/roebel/tmp/svp_basic_transformer/build/CMakeTmp/./CMAKE_T
> >RY_COMPILE.build/Debug/XCODE_DEPEND_HELPER.build/Script-685980685980685980
> >00000 0.sh
> >/bin/sh:
> > /Users/roebel/tmp/svp_basic_transformer/build/CMakeTmp/./CMAKE_TRY_COM
> > PILE.build/Debug/XCODE_DEPEND_HELPER.build/Script-68598068598068598000000
> >0.sh: /bin/sh: bad interpreter: Text file busy
> >** BUILD FAILED **
> >
> >All configuration tests therefore have more or less random values, because
> >they fail either due to the fact that the tested condition is false or
> > because the compiler fails completely. The systems I am working with are
> > dual processor machines and I suppose that has something to do with these
> > errors. cmake is version 2.2.3. Are there any known solutions?
>
> This is a bug in xcodebuild.  CMake 2.4.1 contains a work around.  There
> is a program called cmakexbuild that will forward to xcodebuild, and if
> it sees text file busy, it will re-run the build.   CMake 2.4.1 uses
> this for try-compile tests and ctest builds so that things are more
> predicable.
>
> >The third  problem is probably my missing understanding.  I wanted to
> >overwrite the configuration types, however,
> >SET(CMAKE_CONFIGURATION_TYPES "Release;Debug" CACHE STRING "Configuration
> >types" FORCE)
>
> Try this in 2.4.1.
>
> >did not change the value of CMAKE_CONFIGURATION_TYPES .
> >Is this variable read only?
>
> No, that should work.
>
> In summary, give 2.4.1 a try and get back with any other problems.
> There was a lot of work done for Xcode in 2.4.
>
>
> -Bill

-- 
Axel Roebel
IRCAM Analysis/Synthesis Team