Setting CMAKE_C_COMPILER with spaces doesn't work
This is a copy of a downstream bug report, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156901
Summary: environment variable CC supports having spaces as part of the C-compile-command, while CMAKE_C_COMPILER does not. I'm (re-)reporting here to find out what upstream thinks (possibly "Wontfix, use the environment variable"), so I can close it downstream.
Suppose you want to use /usr/bin/mycc as the command to run your C compiler. You can get CMake to use this C compiler in two ways:
- set environment variable CC to the compile command, or
- pass -DCMAKE_C_COMPILER=/usr/bin/mycc Both work. However, with a space in the command, e.g. /usr/bin/my cc (which is a valid-but-annoying filename), only the environment-variable approach works.
This also applies to multi-part compile commands, like /usr/bin/env CCACHE_PREFIX=/tmp/cc /usr/bin/ccache, where setting the environment variable works, and using CMAKE_C_COMPILER does not.
Find attached a sample with a hello-world CMake project, and a Makefile that drives six builds: plain, one that explicitly asks for cc, two that use bin/my cc (with a space) as compiler -- one via environment variable, one via command-line-argument -- and two that use /usr/bin/env FOO=BAR cc as compiler -- same setup. Two targets fail: build-space-cmd and b-multi-cmd. Those are the two that use CMAKE_C_COMPILER to set up the compiler.
Mostly I think the problem is inconsistency between the treatment of the environment variable and the CMake variable; however, CMAKE_C_COMMAND is documented to be a "full path", which a multi-part compile command certainly isn't. The case of bin/my cc though, shows that there is some trickery happening anyway: it is not unconditionally interpreted as a full path.