It's been a while that I've been looking for this, I need a tool to automatically create a makefile for my project
I've seen qmake and cmake, the problem is that I have two targets (Client and server) they both use a common library (which I wrote) and I want it to create two targets for me, cmake and qmake don't do this
ty
set(servers_srcs
server.cpp
foo.cpp
bar.cpp
)
set(client_srcs
client.cpp
xyz.cpp
abc.cpp
)
set(library_srcs
lib.cpp
)
add_library(library ${library_srcs})
add_executable(client ${client_srcs})
target_link_libraries(client library)
target_link_libraries(server library)
This automatically creates your Makefile, with three targets: client server and library.
Related
I'm facing the following scenario:
Existing project which uses cmake
External 3rdparty library which only comes with Makefiles
The difference of my situation compared to existing questions is that I don't need to have cmake to build the 3rdparty library via the Makefile. Instead, the 3rdparty library provides a library.mk Makefile which has variables like LIB_SRCS and LIB_INCS containing all source and header files required to compile the library.
My idea is to include the library.mk into the project's CMakeLists.txt and then adding those $(LIB_SRCS) and $(LIB_INCS) to target_sources().
My question: How can I include library.mk into the existing CMakeLists.txt to get access to the $(LIB_SRCS) and $(LIB_INCS) for adding them to target_sources()? I'm looking for something like this:
include("/path/to/library.mk") # Somehow include the library's `library.mk` to expose variables to cmake.
add_executable(my_app)
target_sources(
my_app
PRIVATE
main.c
$(LIB_SRCS) # Add 3rd-party library source files
$(LIB_INCS) # Add 3rd-party library header files
)
Using include() does not work as the library.mk is not a CMake list/file.
Since you can't be sure that your target system will even have Make on it, the only option is to parse the strings out of the .mk file, which might be easy if the variables are set directly as a list of filenames, or really hard if they are set with expansions of other variables, conditionals, etc. Do this with FILE(STRINGS) cmake doc.
Your plan will only work if the Makefiles are trivial, and do not set important compiler flags, define preprocessor variables, modify the include directory, etc. And if they really are trivial, skip the parsing, and just do something like aux_source_directory(<dir> <variable>) to collect all the sources from the library directory.
You might also consider building and maintaining a CMakeLists.txt for this third-party library. Do the conversion once, and store it as a branch off of the "vendor" main branch in your version control system. Whenever you update, update the vendor branch from upstream, and merge or rebase your modifications. Or just store it in your existing project, referring to the source directory of the 3rd-party stuff.
I need to build csparse library for an Android project. The project supports Make build system.
I am not familiar with use of NDK for Make build. I have used Androids CMake toolchain for building CMake based projects.
I am looking for pointers to usage of NDK for building C++ projects based on Make. I do not want to manually write a CMakeLists.txt for building the project with CMake toolchain because there are too many source files in the csparse project!
Any help is appreciated!
https://developer.android.com/ndk/guides/other_build_systems covers using the NDK with build systems other than ndk-build and CMake. The last section explicitly covers traditional make projects.
OK, It wasn't so difficult. It seems CSparse is a self-contained and does not depend on other linear-algebra libraries such as CHOLMOD, BLAS, LAPACK, Metis... etc
Here is the CMakeLists.txt file from my Android project :
cmake_minimum_required(VERSION 3.4.1)
include_directories(
${CMAKE_CURRENT_SOURCE_DIR}/include/CSparse/Source
)
add_library( # Sets the name of the library.
csparse-lib
# Sets the library as a shared library.
SHARED
# Provides a relative path to your source file(s).
include/CSparse/Source/cs_add.c
include/CSparse/Source/cs_amd.c
include/CSparse/Source/cs_chol.c
include/CSparse/Source/cs_cholsol.c
include/CSparse/Source/cs_compress.c
include/CSparse/Source/cs_counts.c
include/CSparse/Source/cs_cumsum.c
include/CSparse/Source/cs_dfs.c
include/CSparse/Source/cs_dmperm.c
include/CSparse/Source/cs_droptol.c
include/CSparse/Source/cs_dropzeros.c
include/CSparse/Source/cs_dupl.c
include/CSparse/Source/cs_entry.c
include/CSparse/Source/cs_ereach.c
include/CSparse/Source/cs_etree.c
include/CSparse/Source/cs_fkeep.c
include/CSparse/Source/cs_gaxpy.c
include/CSparse/Source/cs_happly.c
include/CSparse/Source/cs_house.c
include/CSparse/Source/cs_ipvec.c
include/CSparse/Source/cs_leaf.c
include/CSparse/Source/cs_load.c
include/CSparse/Source/cs_lsolve.c
include/CSparse/Source/cs_ltsolve.c
include/CSparse/Source/cs_lu.c
include/CSparse/Source/cs_lusol.c
include/CSparse/Source/cs_malloc.c
include/CSparse/Source/cs_maxtrans.c
include/CSparse/Source/cs_multiply.c
include/CSparse/Source/cs_norm.c
include/CSparse/Source/cs_permute.c
include/CSparse/Source/cs_pinv.c
include/CSparse/Source/cs_post.c
include/CSparse/Source/cs_print.c
include/CSparse/Source/cs_pvec.c
include/CSparse/Source/cs_qr.c
include/CSparse/Source/cs_qrsol.c
include/CSparse/Source/cs_randperm.c
include/CSparse/Source/cs_reach.c
include/CSparse/Source/cs_scatter.c
include/CSparse/Source/cs_scc.c
include/CSparse/Source/cs_schol.c
include/CSparse/Source/cs_spsolve.c
include/CSparse/Source/cs_sqr.c
include/CSparse/Source/cs_symperm.c
include/CSparse/Source/cs_tdfs.c
include/CSparse/Source/cs_transpose.c
include/CSparse/Source/cs_updown.c
include/CSparse/Source/cs_usolve.c
include/CSparse/Source/cs_util.c
include/CSparse/Source/cs_utsolve.c
)
add_library(native-lib SHARED native-lib.cpp)
find_library( # Sets the name of the path variable.
log-lib
log)
target_link_libraries( # Specifies the target library.
native-lib
# Links the target library to the log library
# included in the NDK.
${log-lib}
csparse-lib
)
I hope this answer helps others.
I compiled all the information and now iam trying to implement CMake build system for a super project and i really need a guidance here,it would be great to transform all data i acquired by reading about CMake across different sites to practical knowledge
i have a fundamental questions regarding understating CMake Targets
In case of multi directories structure,i want to achieve most portability thus having target for each directory and then use these different targets as link for others in another directories, my goal is to be agile as possible and not be coupled with a certain directory structure, make use of CMake to figure the dependency, where i would be only concerned about targets
my final target is a library of libraries
USE CASE :
First level directory {PROJECT} ( 2 folders ) :
CMakeLists.txt common_env source
First level CMakeLists.txt :
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(dassys)
# iam using this because target scope change with sub-directory
include(common/CMakeLists.txt)
include(src/CMakeLists.txt)
#Add Library
add_library(dassys INTERFACE)
#Creating library
target_link_libraries(dassys INTERFACE
common
src
)
Second Level directory {{PROJECT} /common}(2 folders 1 file ):
cfgd_*** CMakeLists.txt dstdh header.h
Second Level CMakeLists.txt
#Adding Subdirectory
include(${CMAKE_CURRENT_LIST_DIR}/dstdh/CMakeLists.txt)
include(${CMAKE_CURRENT_LIST_DIR}/cfgd_***/CMakeLists.txt)
#add_subdirectory(dstdh)
#add_subdirectory(cfgd_***)
#Add Library
add_library(common INTERFACE)
#Creating library
target_link_libraries(common INTERFACE
dstdh
cfgd_***
)
----------------------------------------------------------------------------------------------------------------------------------
Thrid Level directory { {PROJECT} /common/dstdh }(6 files ):
CMakeLists.txt dassert.h dfloat.h dstdbit.h dstdbool.h dstdint.h dstdio.h dstring.h
Thrid Level CMakeLists.txt
#Adding Library
add_library(dstdh INTERFACE )
target_sources(dstd INTERFACE
${CMAKE_CURRENT_LIST_DIR}/dassert.h
${CMAKE_CURRENT_LIST_DIR}/dfloat.h
${CMAKE_CURRENT_LIST_DIR}/dstdbit.h
${CMAKE_CURRENT_LIST_DIR}/dstdbool.h
${CMAKE_CURRENT_LIST_DIR}/dstdint.h
${CMAKE_CURRENT_LIST_DIR}/dstdio.h
${CMAKE_CURRENT_LIST_DIR}/dstring.h
)
#Add include for Header only library
target_include_directories(dstdh INTERFACE
"${CMAKE_CURRENT_LIST_DIR}/dstdh/"
)
and here is my question, i need to link against dstd library in another directory
how can this be done because as far as i understand
target_link_libraries ( mylib dstd ) should work in different directory because i have target which is dstd INTERFACE library, and i need Cmake to resolve this dependency by finding this target and link against it
i get compilation error as dstdint.h is not found when mylib is being compiled
I have an executable (game engine) which exports symbols (I've used set_target_properties(game PROPERTIES ENABLE_EXPORTS ON)).
I have a bunch of plugins that link to that executable:
foreach(plugin ${PLUGINS})
target_link_libraries(${plugin} game)
endforeach()
They are loaded dynamically with LoadLibrary/dlopen by the executable.
When I press F5 in Visual Studio and I start the game I don't get the changed plugins rebuilt because the game does not depend on them - it's the other way around.
I wanted to do the following:
foreach(plugin ${PLUGINS})
add_dependencies(game ${plugin})
endforeach()
but it introduces a circular dependency between each plugin and the game. How can I solve my F5 problem?
That's a "chicken-and-egg" problem since the game build will generate the import libraries needed by plugin. So you can't build plugin before game.
I've given your scenario a try and
If I force a rebuild in a POST_BUILD step, I get obviously a recursive build call:
add_custom_command(
TARGET game
POST_BUILD
COMMAND ${CMAKE_COMMAND} --build . --target ALL_BUILD --config $<CONFIG>
)
If I construct a separate target as a "runner" target, I would probably confusing others using my project:
file(WRITE nobuild.cpp "")
add_executable(game_runner nobuild.cpp)
set_source_files_properties(nobuild.cpp PROPERTIES HEADER_FILE_ONLY 1)
set_target_properties(game_runner PROPERTIES OUTPUT_NAME "game")
foreach(plugin ${PLUGINS})
add_dependencies(game_runner ${plugin})
endforeach()
So probably your suggestion of re-using the ALL_BUILD target is the best one. And for auto-generating your required .user settings you may find the following interesting:
CMake add_custom_target(): Run custom command using 'Debug->Start Debugging'
I've used the following to test your scenario:
project(TestPlugins)
file(WRITE main.cpp "int main() { return 0; }")
file(WRITE empty.cpp "")
add_executable(game main.cpp)
set_target_properties(game PROPERTIES ENABLE_EXPORTS ON)
set_target_properties(game PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS ON)
add_executable(plugin1 empty.cpp)
add_executable(plugin2 empty.cpp)
set(PLUGINS plugin1 plugin2)
foreach(plugin ${PLUGINS})
target_link_libraries(${plugin} game)
endforeach()
I have a project where there's only a handful of logical groupings for generating static libraries. However for convenience I want to have the library's source code to be managed with more granular folders.
Currently the only way I know to do this in CMake without having a library for each folder is to just list files as you would normally in with their relative paths:
add_library(SystemAbstraction STATIC "Some/Path/File.cpp")
However I can see this getting unwieldy as the project grows in size with all the different paths.
I tried to see if I could have a CMakeLists.txt in each folder and just use a variable in the base CMakeLists.txt when adding library dependencies. But it seems that add_subdirectory doesn't also import variables?
For expanding the scope of a variable inside a subdirectory, use the PARENT_SCOPE option of set. For example, you can test that if you have
# CMakeLists.txt
set(SRCS main.c)
add_subdirectory(foo)
message(${SRCS})
in the root directory and
# foo/CMakeLists.txt
set(SRCS ${SRCS} foo.c PARENT_SCOPE)
in a subdirectory then it will print main.c foo.c, i.e., the variable is correctly imported into the base CMakeLists.txt.
An option would be to use the object library feature of CMake. You still can but doesn't need to organise your CMake script into subdirectories:
add_library(lib1 OBJECT <srcs>)
add_library(lib2 OBJECT <srcs>)
...
add_library(mainlib $<TARGET_OBJECTS:lib1> $<TARGET_OBJECTS:lib2>)
You can set different compile flags for each object library:
target_include_directories(lib1 PRIVATE incl-dir-for-lib1)
target_compile_definitions(lib2 PRIVATE def-for-lib2)
You still need to set link libraries on your main library:
target_link_libraries(mainlib PRIVATE deps-of-lib1 deps-of-lib2)
Related documentation: Object Libraries