[CMake] CMAKE_C*_FLAGS undefined.

Philip Lowman philip at yhbt.com
Sat Apr 4 00:18:38 EDT 2009


On Fri, Apr 3, 2009 at 11:19 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:

> Hi Philip.
>
> Philip Lowman <philip at yhbt.com> writes:
>
> >> I have this:
> >>
> >> add_custom_command(OUTPUT ${LLVM_CONFIG}
> >>  COMMAND echo "flags: ${CMAKE_CXX_FLAGS} ${CMAKE_CPP_FLAGS}
> >> ${CMAKE_C_FLAGS}"
> >> .... more stuff ....
> >>
> >>
> >> When the custom command executes, this is the output:
> >>
> >> flags:
> >>
> >> i.e. the variables are empty, although I previously used add_definitions
> >> to add flags and the makefile uses the optimization flags that
> >> corresponds to the selected build type.
> >>
> >> How can I access the effective values of the flags used when the
> >> makefile is generated?
> >
> > CMAKE_CXX_FLAGS / CMAKE_C_FLAGS is empty by default on Linux unless
> you've
> > modified it which may have been what happened.  The build type specific
> > complilation flags are stored in CMAKE_CXX_FLAGS_<config_type>.
> > CMAKE_CXX_FLAGS is a base that gets prepended to all of the build
> solutions.
> >
> > The command pasted below works for me on CMake 2.6.4 RC3 Win32 using the
> > MinGW generator (it outputs the flags used to compile during a Release
> > build).  If something like this doesn't work for you can you reply with
> your
> > version of CMake and generator you're using?
> >
> > add_custom_target(foo COMMAND C:/cygwin/bin/echo.exe flags:
> > ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE})
>
> CMAKE_CXX_FLAGS_RELEASE works, but it is not enough. It still misses the
> definitions and other options which are passed to the
> compiler. CMAKE_CXX_FLAGS, as noted on my previous message, is empty.
>


> add_custom_command(OUTPUT ${LLVM_CONFIG}
>   COMMAND echo "flags: ${CMAKE_CXX_FLAGS_DEBUG} ${CMAKE_CPP_FLAGS}
> ${CMAKE_C_FLAGS}"
>  COMMAND echo 's!@LLVM_CPPFLAGS@!${CMAKE_CPP_FLAGS}!' > temp.sed
>  COMMAND echo 's!@LLVM_CFLAGS@!${CMAKE_C_FLAGS}!' >> temp.sed
>  COMMAND echo 's!@LLVM_CXXFLAGS@!${CMAKE_CXX_FLAGS}!' >> temp.sed
>  # TODO: Use general flags for linking! not just for shared libs:
>  COMMAND echo 's!@LLVM_LDFLAGS@!${CMAKE_SHARED_LINKER_FLAGS}!' >> temp.sed
>  COMMAND echo 's!@LIBS@!!' >> temp.sed                    # TODO: System
> libs
>  COMMAND echo 's!@LLVM_BUILDMODE@!${CMAKE_BUILD_TYPE}!' >> temp.sed
>  COMMAND sed -f temp.sed < ${LLVM_CONFIG_IN} > ${LLVM_CONFIG}
> # some stuff omitted
>  DEPENDS ${FINAL_LIBDEPS} ${LLVM_CONFIG_IN}
>  COMMENT "Building llvm-config script."
>  )
>
> This builds an script that knows the compiler and linker options used
> for building the libraries. Later, other (third party) software can
> query the script and check those options for ensuring compatibility with
> the libraries.
>
> `configure_file' is not okay because the "configuration" must be
> executed at build time. CMAKE_CXX_FLAGS and co. are also empty at cmake
> time though, so `configure_file' would have the same problem.



You might want to have a look at the COMPILE_DEFINITIONS target property.

Another option of course is you can use configure_file() and substitute in
the preprocessor definitions you care about with #cmakedefine.  Just have it
output to the build tree and read it in with a custom command:

foo.txt.in:
#cmakedefine HAVE_LUA

CMakeLists.txt:

configure_file(foo.txt.in foo.txt)
foo.txt will be in ${CMAKE_CURRENT_BINARY_DIR}... you can use this in custom
commands to your hearts content AFAIK

configure_file() should work with CMAKE_CXX_FLAGS and company, or at least I
think it works.  Can you attach a trivial reproducer of your problem?  I
guess I'm hung up on what variables you're talking about that you think
would change between CMake configure time and building time?  As far as I
know the variables in your Makefile with the sole exception of make
variables like VERBOSE=1 are all determined at CMake time.  configure_file()
should make your life quite a bit easier I think.


-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090404/5c895557/attachment.htm>


More information about the CMake mailing list