0

Background

CMake has the option to pass in an environment variable CFLAGS to prepend to the CMAKE_C_FLAGS environment variable used in compiling. I am using this option running CMake in a windows platform.

Ex (enabling the -Wall compiler flag):

cmake -E env CFLAGS="-Wall" cmake <path-to-source>

The above command is supposed to create a temporary environment and set CFLAGS to -Wall and then run cmake again within this temporary environment. It is a proposed solution in this SO question. HOWEVER, it does not work as expected. The CMAKE_C_FLAGS are not initialized with the CFLAGS passed through. When printing the CMAKE_C_FLAGS at the beginning of the CMakeLists.txt the set value for -Wall does not appear.

This is a distinct functionality from simply setting the CMAKE_C_FLAGS environment value using the -D option specified in the CMake CLI Documentation.

cmake -DCMAKE_C_FLAGS="-Wall" <path-to-source>

Doing so will override the system variables set by CMake which leads to compilation failure. For instance in our project the CMAKE_C_FLAGS can be seen to be by default set to:

CMAKE FLAGS: /DWIN32 /D_WINDOWS /W3

However if the cmake -D code is run, it will overwrite the initial CMAKE_C_FLAGS:

CMAKE FLAGS: -Wall

In the cmake documentation it explains:

CFLAGS - CMake 3.11.4 Documentation

Default compilation flags to be used when compiling C files. Will only be used by CMake on the first configuration to determine CC default compilation flags, after which the value for CFLAGS is stored in the cache as CMAKE_C_FLAGS. For any configuration run (including the first), the environment variable will be ignored if the CMAKE_C_FLAGS variable is defined.

Now there is a workaround for this if one has the ability to adjust the CMakeLists.txt file itself, which is to create a -D option parameter that accepts an arbitrary string and appends it to the CMAKE_C_FLAGS.

if (NOT "${compileOption_C}" STREQUAL "OFF")
    set(CMAKE_C_FLAGS "${compileOption_C} ${CMAKE_C_FLAGS}")
endif()

However this is a bit of a bodge and does not answer why the initial CFLAGS option does not work.

Question

How does one add compiler flags using the CMake CLI without overwriting cached or default CMAKE_C_FLAGS values, knowing that CFLAGS is not working as intended?

yodama
  • 659
  • 1
  • 9
  • 21
  • It's not possible (at least I don't see how it could be possible based on how CMake works) to append compiler flags using the CMake CLI. You'll have to update the CMakelists.txt files to append compiler flags. – fdk1342 Nov 28 '18 at 00:17
  • @Fred that seems to oppose what the documentation states and what [this SO answer](https://stackoverflow.com/questions/44284275/passing-compiler-options-cmake) proposes. – yodama Nov 28 '18 at 00:30
  • Those answers don't append compiler flags. They either make a new build type and change the defaults for that build type or set the CFLAGS to influence the initial values of the default build types. Either way if the CMakelist.txt file contains any target_compile_options commands those will be appended (or prepended) to the flags used. All you can do is add options to the defaults or override the defaults both of which are described in the Background section of the OP. – fdk1342 Nov 28 '18 at 01:02
  • In the case of setting the CFLAGS to influence the initial values of the default build types, wouldn't that be equivalent to prepending compiler flags in the CLI? – yodama Nov 28 '18 at 01:20
  • I guess you could call adding a value to an empty list prepending or appending or whatever. Anyways a CMakeLists.txt can simply set CMAKE_C_FLAGS to anything it wants ignoring anything you did at the command line (for example libvncserver 0.9.11 does this). Which is why I don't think there is an answer to your question. As to why setting CFLAGS didn't work in this case is harder to tell because it does work (in general). The question should probably be updated to clarify that appending isn't strictly needed and that adding -Wall didn't work. – fdk1342 Nov 28 '18 at 02:56
  • Will update accordingly. – yodama Nov 28 '18 at 19:44
  • Not a duplicate. That answer does not answer my question. As stated in the background, the proposed solution in the answer, which I linked in my above comment already, does not work. – yodama Nov 29 '18 at 21:05

0 Answers0