CMake特定于本地工作副本的编译器设置

时间:2012-04-14 01:19:17

标签: cmake

目前在使用gcc时更改编译器标志,我编辑了构建目标的CMakeLists.txt:

if (UNIX)
    add_definitions(-Wall)
    add_definitions(-g)
    #add_definitions(-O2)
endif (UNIX)

这个问题是git接受了这个改变。如果我继续进行此更改,我会惹恼其他开发人员,他们希望使用-O2而不是-g,但是当他们提取不相关的更改时,他们会获得我的版本。通常情况下,我可以从提交中排除此更改,但是当我对CMakeLists.txt文件进行实际更改时,无法避免推送我个人选择的编译标记。

有没有办法告诉CMake在build /目录中创建一个文件(特定于每个工作副本,因此对每个开发人员),个人可以在不触及项目文件的情况下修改他们的心愿(除了构建之外的所有内容) /)。当然,我们的构建/不会提交给git存储库。

当使用Visual Studio而不是gcc时,可能会有所帮助,IDE会通过其UI在build /中修改VS解决方案文件来处理此问题。问题是我们在使用GNU Makefile时没有这样的机制。

我们的项目组织如下:

ourproject/
    bin/
    build/ <-- CMake-generated stuff goes here
    lib/
    src/
        abuildtarget/
        anotherbuildtarget/
            source.cpp
            source.h
            CMakeLists.txt

2 个答案:

答案 0 :(得分:4)

您在此处使用的是CMake。 add_definitions函数不是像你一样添加编译器选项;相反,它是添加预处理器定义,例如add_definitions(-DDEBUG)

当您配置所需的选项时,您要做的是设置CMAKE_<language>_FLAGS。如果您需要标准集,请将其放在CMakeLists.txt文件中,例如:

if(${CMAKE_Fortran_COMPILER_ID} STREQUAL "Intel")                                   
  set(CMAKE_Fortran_FLAGS_RELEASE "-O2 -xhost" CACHE STRING "" FORCE)

  set(CMAKE_Fortran_FLAGS_NODEBUG "-O0" CACHE STRING "" FORCE)
  mark_as_advanced(CMAKE_Fortran_FLAGS_NODEBUG)

  set(CMAKE_Fortran_FLAGS_PROFILING "-O2 -xhost -p" CACHE STRING "" FORCE)
  mark_as_advanced(CMAKE_Fortran_FLAGS_PROFILING)

  set(CMAKE_Fortran_FLAGS_DEBUG
      "-DDEBUG -g -check noarg_temp_created -C -traceback" CACHE STRING "" FORCE)
endif()

Fortran可以替换为CXXC

在这种情况下,CMAKE_<language>_FLAGS_<build type>根据CMAKE_BUILD_TYPE变量设置标志。如果设置为Release,则使用CMAKE_Fortran_FLAGS_RELEASE。我们添加了其他几种可能的构建类型如果用户想要的东西不是标准构建类型之一,那么他们在配置时将CMAKE_<language>_FLAGS设置为他们想要的任何内容,它会覆盖构建类型设置并改为使用用户定义的标志。

答案 1 :(得分:1)

虽然几乎可以肯定有一种更好的方法可以利用cmake来解决您的问题,但这部分问题很容易解决:

  

但是当我对CMakeLists.txt文件进行实际更改时,没有办法避免推高我个人选择的编译标志。

仅当您提交您的特定个人文件更改到本地存储库时才会出现这种情况,即使这样,您也可以git-revert进行推送修补或使用在您的developmentready-to-push-to-other-developers分支之间进行过滤 - 可以找到粗略的想法here,尽管您必须对其进行大量编辑才能从问题示例中删除违规的个人专线。

然后,更好的选择是不提交个人更改。从答案here开始,您可以轻松地对文件进行特定更改。

然而,值得注意的是,如果您对未被忽略的文件进行了未提交的更改,那么您将最终得到一个永久脏的工作树;这可能是也可能不是问题,具体取决于您的合并工作流程等。