I have the CMakeLists.txt for building tests using g++:
file(GLOB sources *.cpp)
foreach(src ${sources})
get_filename_component(src ${src} NAME_WE)
string(REPLACE "our_prefix" "" bin ${src})
add_executable(${bin} ${src})
target_link_libraries(${bin} our options go here)
endforeach()
What I need to do is to add the option -nodefaultlibs to each test. I've tried to do it like this:
file(GLOB sources *.cpp)
foreach(src ${sources})
get_filename_component(src ${src} NAME_WE)
string(REPLACE "our_prefix" "" bin ${src})
add_executable(${bin} ${src})
set_target_properties(${bin} PROPERTIES
INTERFACE_COMPILE_OPTIONS "-nodefaultlibs"
)
target_link_libraries(${bin} our options go here)
endforeach()
But it seems to have no effect. I've also tried to use the command target_compile_options instead of set_target_properties - and it also had no effect.
Cmake generates the link.txt file for each test - I suppose this file describes the building command used for the test. This file doesn't contain my option -nodefaultlibs.
Could you please explain me what is the right way to add the -nodefaultlibs option?
-nodefaultlibs is a linker flag so use set_target_properties(${bin} PROPERTIES LINK_OPTIONS -nodefaultlibs) or target_link_libraries(${bin} PRIVATE -nodefaultlibs) or for CMake 3.2 set_target_properties(${bin} PROPERTIES LINK_FLAGS -nodefaultlibs).
INTERFACE_COMPILE_OPTIONS is used for something else and target_compile_options won't show up on the link line.
The link.txt file isn't always generated. When using MSYS Makefiles the linker flags show up in linklibs.rsp.
Related
I'm working on a project that contain files from the following languages *.c, *.cpp, *.m, *.mm.
In order to provide the correct file properties to each of the types above, I set variable to store the compilation flags per file type, and apply each file it's matching flags :
set(CPP_FLAGS "-x c++ -arch x86_64 -fmessage-length=0 -std=c++11")
set(OBJCPP_FLAGS "-x objective-c++ -std=gnu++11 -stdlib=libc++ ")
set(OBJC_FLAGS "-x objective-c -fobjc-arc")
set(C_FLAGS "-x c -arch x86_64")
function(set_src_files_according_to_language in_source_files)
foreach(src_file ${in_source_files})
if(${src_file} MATCHES .cpp$)
set_source_files_properties(${src_file} PROPERTIES COMPILE_FLAGS "${CPP_FLAGS}")
elseif(${src_file} MATCHES ".mm$")
set_source_files_properties(${src_file} PROPERTIES COMPILE_FLAGS "${OBJCPP_FLAGS}")
elseif(${src_file} MATCHES ".m$")
set_source_files_properties(${SRC_FILE} PROPERTIES COMPILE_FLAGS "${OBJC_FLAGS}")
elseif(${src_file} MATCHES ".c$")
set_source_files_properties(${src_file} PROPERTIES COMPILE_FLAGS "${C_FLAGS}")
endif()
endforeach(SRC)
endfunction()
I wanted to get some advise about whether it's the correct way to achieve this goal?
thanks
I converted an old style makefile to a CMake CMakeLists.txt file so that I can load a project into JetBrain's new CLion IDE.
I thought it would be easy, but I'm stuck at the point of CMake appending some custom compiler flags to the compilation command which cause a compilation error. I don't have enough knowledge of CMake to solve this issue.
Here is the original makefile.
# makefile
# Main Filename to be compiled
MAINFILE = TestProgram
# Paths
DRIVE := C:
COMPILERROOT := $(DRIVE)/GNUHC11
COMPILERPATH := $(COMPILERROOT)/bin
GELROOT := $(DRIVE)/library/gel-hc1x-1.6.1
GELINCLUDESDIR := $(GELROOT)/include
# Compiler, Linker, Object Copy, and Object Dump path
CC := $(COMPILERPATH)/m6811-elf-gcc # compiler
OC := $(COMPILERPATH)/m6811-elf-objcopy # object copy
OD := $(COMPILERPATH)/m6811-elf-objdump # object dump
# Includes
GELINCLUDES += -I$(GELINCLUDESDIR) -I$(GELINCLUDESDIR)/asm-m68hc11/arch-32k
# Compiler Flags
CFLAGS += -Os # turn on optimizer
CFLAGS += -mshort # consider type int to be 16 bits
CFLAGS += -Wl,-m,m68hc11elfb # build for elf file and use memory.x for memory map
CFLAGS += -I. $(GELINCLUDES) # Add current dir and gel library for includes
CFLAGS += -Dmc6811 # Add define to define the processor architecture for gel includes
# C Source codes to be compiled
SRC1 = $(MAINFILE).c
SRC2 = Interrupts.c
SRC3 = Utilities.c
# C Header files dependencies
HDR1 = $(MAINFILE).h
HDR2 = Interrupts.h
HDR3 = Utilities.h
SRCS = $(SRC1) $(SRC2) $(SRC3)
HDRS = $(HDR1) $(HDR2) $(HDR3)
# Elf file to be generated
ELF1 = $(SRC1:.c=.elf)
# Generate Bin file for programming & Assembly dump
$(MAINFILE).bin : $(ELF1)
$(OC) -O binary $(ELF1) $(MAINFILE).bin
$(OD) -xDC --section=.text --section=.vectors $(ELF1) >$(MAINFILE).dump
# Full compile and link
$(ELF1) : $(SRCS) $(HDRS)
$(CC) $(CFLAGS) -o $(ELF1) $(SRCS)
clean ::
del *.dump
del *.elf
del *.bin
And here is my attempt at the CMakeLists.txt file.
cmake_minimum_required(VERSION 2.8.4)
# program names
set(HC11C m6811-elf-gcc.exe)
set(OBJCOPY m6811-elf-objcopy.exe)
set(OBJDUMP m6811-elf-objdump.exe)
# Important project paths
set(LIB_INC_PATH "C:/library/gel-hc1x-1.6.1/include"
"C:/library/gel-hc1x-1.6.1/include/asm-m68hc11/arch-32k")
set(HC11C_PATH "C:/GNUHC11/bin")
# Sets the compiler
# Needs to come before the project function
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_C_COMPILER "${HC11C_PATH}/${HC11C}")
set(MAIN_FILE "TestProgram")
project(${MAIN_FILE})
# Files to be compiled
set(BASE_PATH "${${PROJECT_NAME}_SOURCE_DIR}")
set(INC_PATH "${BASE_PATH}")
set(SRC_PATH "${BASE_PATH}")
set(SRC_FILES "${SRC_PATH}/${MAIN_FILE}.c"
"${SRC_PATH}/Interrupts.c"
"${SRC_PATH}/Utilities.c")
# Attempt to clear the other spurious compiler flags that I don't want,
# and which cause a compiler arguments error.
# This doesn't seem to work - the defaults still appear.
set(CMAKE_C_FLAGS_DEBUG "")
set(CMAKE_C_FLAGS_RELEASE "")
set(CMAKE_C_FLAGS_RELWITHDEBINFO "")
set(CMAKE_C_FLAGS_MINSIZEREL "")
# Compiler flags
set(CWARN "-Wl,-m,m68hc11elfb") # build for elf file and use memory.x for memory map
set(CTUNING "-mshort") # consider type int to be 16 bits
set(COPT "-Os") # turn on optimizer
set(CDEFS "-Dmc6811") # Add define to define the processor architecture for gel includes
set(CFILES "${MAIN_FILE}.c Interrupts.c Utilities.c")
set(CFLAGS "${CDEFS} ${COPT} ${CWARN} ${CTUNING} ${CFILES}")
set(CMAKE_C_FLAGS "${CFLAGS}")
# Project setup
include_directories(${INC_PATH} ${LIB_INC_PATH})
add_executable(${MAIN_FILE} ${SRC_FILES})
set_target_properties(${MAIN_FILE} PROPERTIES OUTPUT_NAME "${MAIN_FILE}.elf")
# Compiling targets
add_custom_target(main ALL ${OBJCOPY} -O binary "${MAIN_FILE}.elf" "${MAIN_FILE}.bin" DEPENDS ${MAIN_FILE})
add_custom_target(dump ALL ${OBJDUMP} -xDC --section=.text --section=.vectors "${MAIN_FILE}.elf" > "${MAIN_FILE}.dump" DEPENDS main)
set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${MAIN_FILE}.dump;${MAIN_FILE}.elf;${MAIN_FILE}.bin")
# Config logging
message("* ")
message("* Project Name:\t${PROJECT_NAME}")
message("* Project Source:\t${SRC_PATH}")
message("* Project Include:\t${INC_PATH}")
message("* Library Include:\t${LIB_INC_PATH}")
message("* ")
message("* Project Source Files:\t${SRC_FILES}")
message("* MAIN_FILE variable:\t${MAIN_FILE}")
message("* ")
message("* C Flags:\t${CMAKE_C_FLAGS}")
message("* ")
Here is the generated compilation command:
C:\GNUHC11\bin\m6811-elf-gcc.exe "-xc" "-Dmc6811" "-Os" "-Wl,-m,m68hc11elfb" "-mshort" "TestProgram.c" "Interrupts.c" "Utilities.c" "-IC:\\DEVELO~1\\source" "-IC:\\library\\gel-hc1x-1.6.1\\include" "-IC:\\library\\gel-hc1x-1.6.1\\include\\asm-m68hc11\\arch-32k" "-v" "-dD" "-E" "-D___CIDR_IGNORE_DEFINITIONS_START"
It would work but for the auto appended "-E" compiler flag at the end which I don't want. The other appended flags "-v" "-dD" and '-D___CIDR..." are also unwanted but do not cause a compilation error like "-E" does. How can I turn these appended flags off?
Thanks in advance for any help.
It seems you are cross-compiling, so the preferred cmake configuration is a bit different than normal.
See http://www.vtk.org/Wiki/CMake_Cross_Compiling for details, pay attention to the "toolchain file".
I have no idea regarding the auto-appended flags.
You can also have a look at the generated CMakeCache.txt file, either with any editor, from CLion itself, or with cmake-gui.
Remember that CLion copies your CMakeLists.txt in a funky temporary directory and runs cmake off the temporary directory, if you want to look at CMakeCache.txt by hand.
What I suggest is to put aside CLion while you are debugging the CMakeLists.txt, and just use cmake or cmake-gui directly from the shell.
Don't give up, both cmake and CLion are two very good programs IMHO :-)
There doesn't seem to be too much information on this one, but I also ran into this issue. In cmake if you do something like
target_compile_options(game PRIVATE /W4 /WX /wd4100 /wd4200 /wd4201 /FAs /EHsc /Gh /GH)
this will add those options for all compilers in that target.
You can use a generator if you want to add language specific options, so I changed it to:
target_compile_options(game PRIVATE
$<$<COMPILE_LANGUAGE:C>:/W4 /WX /wd4100 /wd4200 /wd4201 /FAs /EHsc /Gh /GH>)
which works.
I am very new to Cmake and need to generate some files at compile time. once generated i need to compile and link the files. I ve created the cmake makefile to compile the already generated files like
cmake_minimum_required(VERSION 2.6)
project(demo)
set(CMAKE_CXX_FLAGS "-DWITH_COOKIES")
add_library(soapC soapC.cpp soapVimBindingProxy.cpp)
add_library(stdsoap2 /home/abdullah/installs/gsoap-shah_edits/gsoap/stdsoap2.cpp)
add_executable(demo test_file.cc test_app.cc)
target_link_libraries(demo soapC stdsoap2 gsoap++)
This successfully compiles the project. However the files soapC.cpp soapVimBindingProxy.cpp needs to be generated first. And I want to generate these files at runtime using the gsoap tool.
following is the command that needs to be run to generate the header file
wsdl2h -o outfile.h infile.wsdl
This takes an input wsdl file and creates a corresponding outfile.h.
Now I tried doing this in cmake like this
cmake_minimum_required(VERSION 2.6)
add_custom_command(
OUTPUT vsphere.h
COMMAND wsdl2h -o vsphere.h vim25/vim.wsdl
)
But something goes wrong here. No error pops up but no file is created either. Am I missing something ? All help much appreciated.
Thanks.
You've just created a command for producing your header file, so CMake knows just where to get vsphere.h from. I'd recommend using OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/vsphere.h in the add_custom_command() call.
Now you need to create a target:
add_custom_target(vsphere_header ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/vsphere.h)
Finally, make your soapC target depend on it:
add_dependencies(soapC vsphere_header)
Be sure to place add_dependencies() call after soapC target definition.
Thanks arrododger and TobyHijzen for your lighting on this issue.
I use add_custom_command with main_dependency feature for solution for this issue. Following is my CMakeLists.txt for famous calc example of gsoap tutorial.
cmake_minimum_required(VERSION 2.8)
# Proejct name
PROJECT(Calculator)
# Make verbose level on/off
SET(CMAKE_VERBOSE_MAKEFILE ON)
# Varialbes used in cmake
SET(TARGET calc_client)
SET(GSOAP_STATIC_LIB gsoap)
SET(CLIENT_SRC calc_client.c)
SET(WSDL2H_EXEC wsdl2h)
SET(WSDL2H_IN http://www.genivia.com/calc.wsdl)
#SET(WSDL2H_IN calc.wsdl)
SET(WSDL2H_OUT calc.h)
SET(WSDL2H_OPT -c -o)
# command for generating stub and xml serializer code
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${WSDL2H_OUT}
COMMAND ${WSDL2H_EXEC} -c -ttypemap.dat -o ${WSDL2H_OUT} ${WSDL2H_IN}
COMMENT "=================== Generating ${WSDL2H_OUT} gSOAP Header file ..."
)
SET(SOAPCPP2_EXEC soapcpp2)
SET(STUB soapClient.c soapC.c)
SET(SOAPCPP2_OUT
${STUB}
calc.add.req.xml
calc.add.res.xml
calc.sub.req.xml
calc.sub.res.xml
calc.mul.req.xml
calc.mul.res.xml
calc.div.res.xml
calc.div.req.xml
calc.pow.res.xml
calc.pow.req.xml
calc.nsmap
soapH.c
soapH.h
soapStub.h
soapClientLib.c
)
# command for generating stub and xml serializer code
ADD_CUSTOM_COMMAND(
OUTPUT ${STUB}
COMMAND ${SOAPCPP2_EXEC} -c -C ${WSDL2H_OUT}
MAIN_DEPENDENCY ${WSDL2H_OUT}
COMMENT "=================== Generating ${STUB} outputs ..."
)
# Exutable files and dependents
ADD_EXECUTABLE(${TARGET} ${CLIENT_SRC} ${STUB})
# libraries for taget : for gcc -l option
TARGET_LINK_LIBRARIES(${TARGET} ${GSOAP_STATIC_LIB})
# Compiler options
ADD_DEFINITIONS(-Wall -O2 -s)
I was wondering if there was any sample code for Makefiles (make) and CMakeLists.txt (cmake) that both do the same thing (the only difference being that one is written in make and the other in cmake).
I tried looking for 'cmake vs make', but I never found any code comparisons. It would be really helpful to understand the differences, even if just for a simple case.
The following Makefile builds an executable named prog from the sources
prog1.c, prog2.c, prog3.c and main.c. prog is linked against libmystatlib.a
and libmydynlib.so which are both also built from source. Additionally, prog uses
the library libstuff.a in stuff/lib and its header in stuff/include. The
Makefile by default builds a release target, but offers also a debug target:
#Makefile
CC = gcc
CPP = g++
RANLIB = ar rcs
RELEASE = -c -O3
DEBUG = -c -g -D_DEBUG
INCDIR = -I./stuff/include
LIBDIR = -L./stuff/lib -L.
LIBS = -lstuff -lmystatlib -lmydynlib
CFLAGS = $(RELEASE)
PROGOBJS = prog1.o prog2.o prog3.o
prog: main.o $(PROGOBJS) mystatlib mydynlib
$(CC) main.o $(PROGOBJS) $(LIBDIR) $(LIBS) -o prog
debug: CFLAGS=$(DEBUG)
debug: prog
mystatlib: mystatlib.o
$(RANLIB) libmystatlib.a mystatlib.o
mydynlib: mydynlib.o
$(CPP) -shared mydynlib.o -o libmydynlib.so
%.o: %.c
$(CC) $(CFLAGS) $(INCDIR) $< -o $#
%.o: %.cpp
$(CPP) $(CFLAGS) $(INCDIR) -fPIC $< -o $#
Here is a CMakeLists.txtthat does (almost) exactly the same, with some comments to underline the
similarities to the Makefile:
#CMakeLists.txt
cmake_minimum_required(VERSION 2.8) # stuff not directly
project(example) # related to building
include_directories(${CMAKE_SOURCE_DIR}/stuff/include) # -I flags for compiler
link_directories(${CMAKE_SOURCE_DIR}/stuff/lib) # -L flags for linker
set(PROGSRC prog1.c prog2.c prog3.c) # define variable
add_executable(prog main.c ${PROGSRC}) # define executable target prog, specify sources
target_link_libraries(prog mystatlib mydynlib stuff) # -l flags for linking prog target
add_library(mystatlib STATIC mystatlib.c) # define static library target mystatlib, specify sources
add_library(mydynlib SHARED mydynlib.cpp) # define shared library target mydynlib, specify sources
#extra flags for linking mydynlib
set_target_properties(mydynlib PROPERTIES POSITION_INDEPENDENT_CODE TRUE)
#alternatively:
#set_target_properties(mydynlib PROPERTIES COMPILE_FLAGS "-fPIC")
In this simple example, the most important differences are:
CMake recognizes which compilers to use for which kind of source. Also, it
invokes the right sequence of commands for each type of target. Therefore, there
is no explicit specification of commands like $(CC) ..., $(RANLIB) ... and so on.
All usual compiler/linker flags dealing with inclusion of header files, libraries, etc.
are replaced by platform independent / build system independent commands.
Debugging flags are included by either setting the variable CMAKE_BUILD_TYPE to "Debug",
or by passing it to CMake when invoking the program: cmake -DCMAKE_BUILD_TYPE:STRING=Debug.
CMake offers also the platform independent inclusion of the '-fPIC' flag (via
the POSITION_INDEPENDENT_CODE property) and many others. Still, more obscure settings can be implemented by hand in CMake just as well as in a Makefile (by using COMPILE_FLAGS
and similar properties). Of course CMake really starts to shine when third party
libraries (like OpenGL) are included in a portable manner.
The build process has one step if you use a Makefile, namely typing make at the command line. For CMake, there are two steps: First, you need to setup your build environment (either by typing cmake <source_dir> in your build directory or by running some GUI client). This creates a Makefile or something equivalent, depending on the build system of your choice (e.g. make on Unixes or VC++ or MinGW + Msys on Windows). The build system can be passed to CMake as a parameter; however, CMake makes reasonable default choices depending on your system configuration. Second, you perform the actual build in the selected build system.
Sources and build instructions are available at https://github.com/rhoelzel/make_cmake.
Grab some software that uses CMake as its buildsystem (there's plenty of opensource projects to choose from as an example). Get the source code and configure it using CMake. Read resulting makefiles and enjoy.
One thing to keep in mind that those tools don't map one-to-one. The most obvious difference is that CMake scans for dependencies between different files (e.g. C header and source files), whereas make leaves that to the makefile authors.
If this question is about a sample Makefile output of the CMakeList.txt file then please check the cmake-backend sources and generate one such Makefile. If it is not then adding to the reply of #Roberto I am trying to make it simple by hiding the details.
CMake function
While Make is flexible tool for rules and recipe, CMake is a layer of abstraction that also adds the configuration feature.
My plain CMakeLists.txt will look like the following,
cmake_minimum_required(VERSION 2.8)
project(example)
file(GLOB testapp_SOURCES *.cc)
add_executable(testapp ${testapp_SOURCES})
Note, that CMake hides how the build can be done. We only specified what is the input and output.
The CMakeLists.txt contains list of function-calls that are defined by cmake.
(CMake function) Vs Make rules
In Makefile the rules and recipes are used instead of functions . In addition to function-like feature, rules and recipes provide chaining. My minimalistic Makefile will look like the following,
-include "executable.mk"
TARGETS=testapp.bin
all:${TARGETS}
While the executable.mk will look like the following,
SOURCES=$(wildcard *.cpp)
OBJECTS=$(SOURCES:.cpp=.o)
DEPS=$(SOURCES:.cpp=.d)
%.bin:$(OBJECTS)
$(CC) $(CFLAGS) -o $# $^ $(LFLAGS) $(LIBS)
.PHONY: all clean
clean:
$(RM) $(OBJECTS) $(DEPS) $(TARGETS)
-include $(DEPS)
Starting from the scratch I shall start with a Makefile like the following,
all: testapp.bin
testapp.bin:sourcea.o sourcb.o
$(CC) $(CFLAGS) -o $# $^ $(LFLAGS) $(LIBS)
.PHONY: all clean
clean:
$(RM) $(OBJECTS) testapp.bin
I got this snippet from here and modified it. Note that some implicit-rules are added to this file which can be found in the makefile-documentation. Some implicit variables are also relevant here.
Note, that Makefile provides the detail recipe showing how the build can be done. It is possible to write executable.mk to keep the details defined in one file. In that way the makefile can be reduced as I showed earlier.
Internal Variables in CMake and Make
Now getting little advanced, in CMake we can set a compiler flag like the following,
set(CMAKE_C_FLAGS "-Wall")
Please find out more about CMake default variables in CMakeCache.txt file.
The CMake code above will be equivalent to Make code below,
CFLAGS = -Wall
Note that CFLAGS is an internal variable in Make, the same way, CMAKE_C_FLAGS is internal variable in CMake .
adding include and library path in CMake
We can do it in cmake using functions.
target_include_directories(testapp PRIVATE "myincludes")
list(APPEND testapp_LIBRARIES
mytest mylibrarypath
)
target_link_libraries(testapp ${testapp_LIBRARIES})
Vs adding include and library path in Make
We can add include and libraries by adding lines like the following,
INCLUDES += -Imyincludes
LIBS += -Lmylibrarypath -lmytest
Note this lines above can be generated from auto-gen tools or pkg-config. (though Makefile is not dependent of auto-config tools)
CMake configure/tweek
Normally it is possible to generate some config.h file just like auto-config tools by using configure_file function. It is possible to do more trick writing custom functions. And finally we can select a config like the following,
cmake --build . --config "Release"
It is possible to add some configurable option using the option function.
Makefile configure/tweak
If somehow we need to compile it with some debug flag, we can invoke the make like,
make CXXFLAGS=NDEBUG
I think internal variables, Makefile-rules and CMake-functions are good start for the comparison, good luck with more digging.
I have a structure of code like this:
project_dir/
source1.c
subdir/
source2.c
The Makefile calls subdir/Makefile, so that the file subdir/source2.c is compiled in this way:
gcc -g -someoptions source2.c
and symbols in GDB link to source2.c instead of subdir/source2.c (with the result that GDB can not find symbols in source files). How should I write a Makefile or what options to use in gcc to get symbols using the relative path to the project main directory (or eventually the absolute path)?
I can not use:
cd .. && gcc -g -someoptions ../subdir/source2.c
because I would have to change references to header files in all files in subdir.
Your question is platform-specific (e.g. on Linux GDB should just work(TM), so I assume you are not on Linux).
One option is to build like this:
gcc -g ${PWD}/source2.c -o ...
Another option is to use GDB dir command to add ${TOP}/project_dir/subdir to the list of directories that GDB will search for sources.