I'm struggling to get Cmake to compile a C++ project into a static .lib file so I can then link it another project. Here's my basic setup:
cmake_minimum_required (VERSION 2.8)
PROJECT (MyProj)
IF (NOT ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} LESS 3.1)
cmake_policy(SET CMP0054 OLD)
ENDIF ()
set(SRCS_COMMON
#Here I locate the relative paths to a bunch of .cpp files
#../../Source/Common/Math/Example.cpp
)
ADD_LIBRARY(MyProj_static STATIC ${SRCS_COMMON})
TARGET_INCLUDE_DIRECTORIES(MyProj_static PRIVATE ../../Include)
SET_TARGET_PROPERTIES(MyProj_static PROPERTIES OUTPUT_NAME MyProj_static)
When I run CMake, I don't necessarily want to create a *.vcxproj file for my project. Rather, I simply want it to compile this project into a .lib file so it can be linked to another target. Thoughts?
CMake isn't a standalone build tool, so you can't build your code with just it. You can generate NMake makefiles or Ninja if you want to do without .vcxproj.
In the latter case make sure you run CMake from within "Visual Studio Developer Prompt".
Related
I have never worked with CMake before, so please forgive any rookie mistakes. Most of the following working frame has been given to me by my project group.
The goal is to build GoogleTest into a .dll, to be used in different, indepentent parts of our project. I'm having troubles setting up CMake the right way.
The work-flow so far has been:
Clone gtest from git --> also downloads a CMake List file
Alter variables in CMakeCache.txt to have it produce a Code::Blocks project file
Compile the project file in Code::Blocks
So far, it produces a static library (.a files) that can be used in our project. I'm having troubles genereating .dll files.
Variables I have tried changing:
BUILD_SHARED_LIBS:BOOL=ON --> the files generated by Code::Blocks now have a .dll.a double extension
CMAKE_C_FLAGS and all the corresponding C++ flags where set to -DGTEST_CREATE_SHARED_LIBRARY=1 as given here
CMAKE_EXE_LINKER_FLAGS has been set to -shared to make the linker produce .dll files
I have worked my way through the GoogleTest documentation here and here but in both, building it into a .dll is merely a 2-sentence-topic.
As #Tsyvarev pointed out, the .dll files were created in a (very) different folder.
I'm currently changing the build system on my project, from gnu makefiles to cmake (that generate makefiles).
My project generates several libraries (.lib), and several executables (.exe).
Currently i generate the makefiles using the following command :
cmake -G "Unix Makefiles" .. -DCMAKE_BUILD_TYPE=Debug
The generated makefiles contain an all target, as well as a target for every executable (compiled as such with the add_executable cmake directive), so i can compile a subset of the project (which saves a lot of time) : make executable_1; make executable_2 and so on.
However, there is no target for the libraries (compiled as such with the add_library cmake directive) so i cannot do make library_1 for example. I want to do this because it would save a lot of time.
I tried to add a dummy executable in the library's cmake, and link the library to this executable (which only contains a main without actually using library_1's code).
add_library(library_1 test.cpp)
add_executable(dummy_exe dummy_main.cpp)
target_link_library(dummy_exe library_1)
It does add a target for dummy_exe but does not build the library because it does not actually need to link any of the library_1's code.
This was a workaround attempt anyway, and i'd rather just call make library_1 after all. Is there any way to add a makefile target for a library using cmake ?
As answered by w-m and Fred, CMAKE indeed create a target for libraries in the Makefile.
I was trying to build the library with the cmake subproject name of the library instead of the library name.
make help was indeed of big help to find this issue, as it lists everything that can be built.
I am a CMake noob trying to put together a package installer so i can move between my windows development machine and my cluster.
I have the following directory tree for my files (an example)
-Primary
--Library Source
--CMakeLists.txt
--src1.cpp
--src1.h
--Application Source
--CMakeLists.txt
--src1.cpp
--src1.h
--CMakeLists.txt
Each CMakeLists.txt is
Primary/CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(BloodVesselRadiationDamageSimulations CXX)
SET(FIND_LIBRARY_USE_LIB64_PATHS true)
SET(CMAKE_INSTALL_PREFIX ${CMAKE_SOURCE_DIR}) #only for testing
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_ROOT}/ ${CMAKE_SOURCE_DIR}/cmake/Modules/")
FIND_PACKAGE(OpenMP)
FIND_PACKAGE(MPI)
FIND_PACKAGE(HDF5)
FIND_PACKAGE(GTest)
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /MT")
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /MTd")
SET(CMAKE_DEBUG_POSTFIX _d)
ADD_SUBDIRECTORY(Source)
ADD_SUBDIRECTORY(SourceUnitTest)
Library Source/CMakeLists.txt
ADD_LIBRARY(VesselProjectBaseLibrary STATIC Src1.cpp
Src1.h)
INSTALL(TARGETS VesselProjectBaseLibrary DESTINATION x64/Debug CONFIGURATIONS Debug)
INSTALL(TARGETS VesselProjectBaseLibrary DESTINATION x64/Release CONFIGURATIONS Release|RelWithDebInfo)
Application Source/CMakeLists.txt
INCLUDE_DIRECTORIES("${GTEST_INCLUDE_DIRS}")
ADD_EXECUTABLE (SourceUnitTests Src1.cpp
Src1.h)
TARGET_LINK_LIBRARIES(SourceUnitTests ${GTEST_LIBRARY})
TARGET_LINK_LIBRARIES(SourceUnitTests debug VesselProjectBaseLibrary_d optimized VesselProjectBaseLibrary)
I am able to generate the projects correctly; I see all the correct files in the projects. However, when i go to compile the debug build I get the following error:
1>ipo: : error #11018: Cannot open VesselProjectBaseLibrary_d.lib
1>LINK : fatal error LNK1104: cannot open file 'VesselProjectBaseLibrary_d.lib'
If i compile my release build everything works perfectly and compilation is successful. The library compiles successfully under both builds.
When you link against a library created within the project, you need to specify library target name, not a library file. CMake will care about proper filename, path and other things:
TARGET_LINK_LIBRARIES(SourceUnitTests VesselProjectBaseLibrary)
Variable CMAKE_DEBUG_POSTFIX affects on library's filename. While file VesselProjectBaseLibrary_d.lib is actually created in debug build, it cannot be found automatically by the linker. Again, use target name and let CMake do all other work.
I have a small project with a Makefile which I'm trying to convert to CMake, mostly just to get experience with CMake. For purposes of this example, the project contains a source file (C++, though I don't think the language is particularly relevant) and a static library file which I've copied from elsewhere. Assume for argument's sake that the source code to the library is unavailable; I only have the .a file and the corresponding header.
My handmade Makefile contains this build rule:
main: main.o libbingitup.a
g++ -o main main.o libbingitup.a
which works fine. How do I tell CMake to reproduce this? Not literally this exact makefile, of course, but something that includes an equivalent linking command. I've tried the obvious but naive ways, like
add_executable(main main.cpp libbingitup.a)
or
add_executable(main main.cpp)
target_link_libraries(main libbingitup.a)
as well as various things with link_directories(.) or add_library(bingitup STATIC IMPORTED) etc. but nothing so far that results in a successful linkage. What should I be doing?
Version details: CMake 2.8.7 on Linux (Kubuntu 12.04) with GCC 4.6.3
CMake favours passing the full path to link libraries, so assuming libbingitup.a is in ${CMAKE_SOURCE_DIR}, doing the following should succeed:
add_executable(main main.cpp)
target_link_libraries(main ${CMAKE_SOURCE_DIR}/libbingitup.a)
If you don't want to include the full path, you can do
add_executable(main main.cpp)
target_link_libraries(main bingitup)
bingitup is the same name you'd give a target if you create the static library in a CMake project:
add_library(bingitup STATIC bingitup.cpp)
CMake automatically adds the lib to the front and the .a at the end on Linux, and .lib at the end on Windows.
If the library is external, you might want to add the path to the library using
link_directories(/path/to/libraries/)
I found this helpful...
http://www.cmake.org/pipermail/cmake/2011-June/045222.html
From their example:
ADD_LIBRARY(boost_unit_test_framework STATIC IMPORTED)
SET_TARGET_PROPERTIES(boost_unit_test_framework PROPERTIES IMPORTED_LOCATION /usr/lib/libboost_unit_test_framework.a)
TARGET_LINK_LIBRARIES(mytarget A boost_unit_test_framework C)
I want to add to the other comments, the project name is the first argument. I had a project called cmakecompile and i wanted to add libusb to it, the code is as follows,
add_executable(cmakecompile main.c)
target_link_libraries(cmakecompile "D:/msys2/mingw64/lib/libusb-1.0.a")
the project had just only a main.c file, the first parameter in target_link_libraries is the name of your project and the second parameter is the path of the library.
Note that may help: Since i am compiling under windows, i had to install msys2 because the library you have has to be compiled with the same compiler. For example if you get libusb and try to use it in a qt-creator project, it will not work and you may get unreferenced functions, therefore i had to install msys2 and install libusb from inside msys2, install make and create a QT Cmake project and compile from Qt creator using the msys2 make.
The full cmakelists.txt is as follow
cmake_minimum_required(VERSION 3.5)
project(cmakecompile LANGUAGES C)
add_executable(cmakecompile main.c)
target_link_libraries(cmakecompile "D:/msys2/mingw64/lib/libusb-1.0.a")
Introduction:
I am trying to use CMake to obtain cross platform compilation scripts (for VS 9.0 on a Windows32 and Makefiles for Unix).
I am experiencing something i can't understand about add_subdirectory().
Let me show you my code :
Context:
My architecture for a module named "module1" is something like this :
CMakeLists.txt
include/
file1.h
file2.h
*.h
src/
file1.cpp
file2.cpp
*.cpp
test/
CMakeLists.txt
src/
testfile1.cpp
testfile2.cpp
The architecture of my whole application is composed of these modules which are in themselves projects that could work independantly.
My goals:
I want to compile my module as a library
I want to test the library with the code in the test/ folder
Here are the CMakeLists i wrote :
This one is the CMakeLists.txt in the root directory of my module.
#ENSURE MINIMUM VERSION OF CMAKE
cmake_minimum_required(VERSION 2.8)
#CONFIGURATION OF THE PROJECT
#NAME OF THE PROJECT
project(MyProject)
#OUTPUT OF THE PROJECT
set(LIBRARY_OUTPUT_PATH lib/${CMAKE_BUILD_TYPE})
#ADD THE HEADERS OF THE LIBRARY BEING CREATED
include_directories(include)
#ADD 3rd PARTY OPENCV LIBRARIES
find_package(OpenCV REQUIRED)
#ADD 3rd PARTY XERCES LIBRARIES
include_directories(${XERCES_INCLUDE_DIR})
link_directories(${XERCES_LIB_DIR})
set(Xerces_LIBS xerces-c_3D.lib)
#CONFIGURATION OF THE LIBRARY
file(GLOB_RECURSE MYPROJECT_MODULE_CXX src/*)
file(GLOB_RECURSE MYPROJECT_MODULE_HDR include/*)
#NAME OF THE PRESENT LIBRARY
set(MYPROJECT_MODULE_LIB_NAME myModuleLib)
add_library(${MYPROJECT_MODULE_LIB_NAME}
SHARED
${MYPROJECT_MODULE_CXX}
${MYPROJECT_MODULE_HDR}
)
target_link_libraries(${MYPROJECT_MODULE_LIB_NAME}
${OpenCV_LIBS}
${Xerces_LIBS}
)
#CONTINUE IN THE SUB FOLDERS
add_subdirectory(test)
And then, in the test/ folder, here is the CMakeLists.txt
#ENSURE MINIMUM VERSION OF CMAKE
cmake_minimum_required(VERSION 2.8)
#CONFIGURATION OF THE PROJECT
#NAME OF THE PROJECT
project(MyProjectTest)
#OUTPUT OF THE PROJECT
set(EXECUTABLE_OUTPUT_PATH bin/${CMAKE_BUILD_TYPE})
#ADD OUR TESTED LIBRARY
include_directories(../include)
link_directories(../build/lib/${CMAKE_BUILD_TYPE})
#CONFIGURATION OF THE EXE
file(GLOB_RECURSE MYPROJECT_MODULE_TEST_CXX src/*)
#NAME OF THE PRESENT EXECUTABLE
set(MYPROJECT_MODULE_TEST_BIN_NAME myModuleTest)
add_executable(${MYPROJECT_MODULE_TEST_BIN_NAME}
${MYPROJECT_MODULE_TEST_CXX}
)
target_link_libraries(${MYPROJECT_MODULE_TEST_BIN_NAME}
${MYPROJECT_MODULE_LIB_NAME}
)
Question
The CMake outputs a correct MyProject.sln Visual Studio 9.0 solution, which compiles successfully in my library linked with OpenCV and Xerces (and other 3rd part libraries). However the test binary did not output any MyProjectTest.sln.
I thought, (and read in the CMake documentation) that add_subdirectory(dir) was used to do CMake in the following sub directory (i mean, the name could not be clearer :p !), so shouldn't it continue CMake in the test/ directory and create my MyProjectTest.sln solution ?
I use the GUI CMake to run the root CMakeLists.txt in a build directory that i create in the root of my module. When I explore the build directory that's where I can find my MyProjet.sln, a test/ folder, but no MyProjectTest.sln in it !
This may not solve your original problem but in your test/folder/CMakeLists.txt try changing
#ADD OUR TESTED LIBRARY
include_directories(../include)
link_directories(../build/lib/${CMAKE_BUILD_TYPE})
to
#ADD OUR TESTED LIBRARY
include_directories(${CMAKE_SOURCE_DIR}/include)
link_directories(${CMAKE_BINARY_DIR}/lib/${CMAKE_BUILD_TYPE})
otherwise you are assuming that your build folder is always named build.
After three days trying everything, I finally found the answer... Sir DLRdave was right actually: the problem was not from the code itself but from something "out of the code".
Problem found:
I created and edited all my files with Notepad++. Actually when opening the files with windows notepad (because i was curious) a strange rectangle symbol appeared and the file did not look like the one I usually see on Notepad++
I found out that the symbol was a "\n\r" that Notepad++ did not show me (it must be filtered) but going on windows notepad, you could see that the whole file was "impure" and appeared on a single line instead of the layout i saw on Notepad++.
As this "encoding" bug appeared only in the subdirectory CMakeLists, it could not be read but said no error when interpreting with CMake and that's probably why I had no returned error from running CMake.
Solution:
I used the native2ascii.exe tool from Java to correct the encoding error.
The why:
Actually what it probably means is that the syntaxic parser of CMake has probably not been designed for filtering this type of char appearing with strange encoding, that's why it gave me 3 days of intense debugging.