On 11/18/2011 06:17 PM, Paul Hansen wrote: > Thank you very much for the answers, David and Michael. > > I am trying to get a QNX compiler to work with CMake. My host comp runs > Ubuntu. > I did: > > cmake -G "Unix Makefiles -D CMAKE_C_COMPILER=qcc -D CMAKE_CXX_COMPILER=QCC > .. > but get > dpkg-architecture: warning: Couldn't determine gcc system type, falling > back to default (native compilation) > cc: unknown option: '-dumpmachine' > > I have of course google'd and found out that I probably have to make a new > toolchain file. > Does that seem correct?
Yes, it does. > qcc is basicly gcc with modifications and other libraries. > Is there an example toolchain file I can use as basis? > > Is there any documentation about what should be set up in a toolchain file? http://www.cmake.org/Wiki/CMake_Cross_Compiling and the ML, of course. Regards, Michael > On Fri, Nov 18, 2011 at 2:26 PM, Michael Hertling <mhertl...@online.de>wrote: > >> On 11/17/2011 05:18 PM, Paul Hansen wrote: >>> Hi >>> >>> I have a project that has to be compiled with two different compilers on >>> the same computer. >>> >>> Can I do that from the same CMakeLists.txt file? >> >> What do you mean exactly? >> >> (1) Compile the project twice, each time completely with a different >> compiler? If so, use two different build trees, as already outlined >> in the meantime. >> >> (2) A part of your project must be compiled with a different compiler >> than the remaining parts? Difficult - besides a custom-command-based >> approach, you might outsource the concerned part and reintegrate it >> as an external project which can be configured independently with a >> different toolchain. Look at the following example: >> >> # CMakeLists.txt: >> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR) >> PROJECT(MAIN C) >> SET(CMAKE_VERBOSE_MAKEFILE ON) >> SET(SUBCC ${CMAKE_C_COMPILER} CACHE FILEPATH "Subproject C compiler") >> INCLUDE(ExternalProject) >> ExternalProject_Add(sub >> SOURCE_DIR ${CMAKE_SOURCE_DIR}/sub >> CMAKE_CACHE_ARGS >> -DCMAKE_C_COMPILER:FILEPATH=${SUBCC} >> -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/sub) >> ADD_LIBRARY(f SHARED IMPORTED) >> SET_TARGET_PROPERTIES(f PROPERTIES >> IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/sub/lib/libf.so) >> ADD_DEPENDENCIES(f sub) >> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n") >> ADD_EXECUTABLE(main main.c) >> TARGET_LINK_LIBRARIES(main f) >> ADD_DEPENDENCIES(main f) >> >> sub/CMakeLists.txt: >> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR) >> PROJECT(SUB C) >> SET(CMAKE_VERBOSE_MAKEFILE ON) >> FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n") >> ADD_LIBRARY(f SHARED f.c) >> INSTALL(TARGETS f LIBRARY DESTINATION lib) >> >> Configure with the desired SUBCC to see the subproject being built with >> that instead of the overall project's C compiler. The downside is that >> you can't use FIND_*() on the subproject's targets since they're built >> after the overall project is already configured, so you must predict >> their locations. Additionally, there may be issues w.r.t. the correct >> handling of dependencies. Moreover, if the subproject is to share the >> overall project's cache, you need to pass the concerned variables to >> ExternalProject_Add() individually, or do some trickery with LOAD_ >> CACHE(). Alternatively, you might use the so-called super-build >> approach, but be prepared for other issues then, cf. [1]. >> >>> Specifically I am wondering: >>> - CMake finds a compiler and makes a test. A colleague has tried to >> change >>> the compiler variables but CMake made the test and overwrote his settings >>> (from the CMakeLists.txt file) in CMakeCache.txt >> >> The toolchain can't be changed without a complete reconfiguration, and >> during the latter, CMake even forgets the cache settings specified on >> the command line, cf. [2]. >> >>> - With target_link_directories I can point out specifically which >> libraries >>> should be used with each executable. But what about header files? >>> include_directories() is not specified for each executable. Is there >> anyway >>> to control what is in the include path at different points in the >>> CMakeLists.txt. I have tried to use set_directory_properties(PROPERTIES >>> INCLUDE_DIRECTORIES "") to reset include path at one point. The deletion >>> works but just not at that specific point on CMakeLists.txt. >> >> The INCLUDE_DIRECTORIES directory property is read-only. >> >>> - If split up into compiler1.cmake and compiler2.cmake I still get the >>> include_directories() problem since values are "inherited" >> >> In general, I'd recommend to invoke INCLUDE_DIRECTORIES() sufficiently >> deep within the CMakeLists.txt files' hierarchy to limit the scope of >> its impact. Possibly, you even need to reorganize your project a bit, >> i.e. split one CMakeLists.txt in two and have INCLUDE_DIRECTORIES() >> called for the latters with the correct directories separately. >> >> Regards, >> >> Michael >> >> [1] http://www.mail-archive.com/cmake@cmake.org/msg36170.html >> [2] http://www.mail-archive.com/cmake@cmake.org/msg37060.html -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake