I'm using an external library without CMake and building this library is a little tedious so I decided to use external scripts for that purpose:
one for configuration which runs the projects own build system, and
one for the actual build which simply runs MSBuild on the generated VS solution.
I want to copy the script to the directory where the archive is unpacked to, and execute it afterwards.
Current CMake File
file(TO_NATIVE_PATH ${CMAKE_CURRENT_LIST_DIR}/scripts/configure_OpenDDS_template.bat CONFIGURE_SCRIPT)
file(TO_NATIVE_PATH ${CMAKE_CURRENT_LIST_DIR}/scripts/build_OpenDDS_template.bat BUILD_SCRIPT)
ExternalProject_Add(OpenDDS
PREFIX OpenDDS
URL ${CLD}/OpenDDS-DDS-3.12.1.zip
CONFIGURE_COMMAND cmd /C "cd ../OpenDDS && copy ${CONFIGURE_SCRIPT} configure_OpenDDS.bat && call configure_OpenDDS.bat"
BUILD_COMMAND copy ${BUILD_SCRIPT} ${BUILD_COPY}
INSTALL_COMMAND "")
My question is whether there is a better or shorter or more elegant solution to have the absolute paths used in CONFIGURE_COMMAND and BUILD_COMMAND in correct Windows form than to use the conversion function from file. My current solution is acceptable for small projects in my opinion but you really want CMake to handle the path conversion for you without the excessive use of additional variables. I mean, CMake already handles the OS specific configuration of absolute paths for normal use but not within functions that execute pure OS commands like execute_process.
Related
I need ExternalProject_Add to invoke just one command for an external project whose makefile does all the needed steps. I need to have that command be "make WITH_OPTION1=no WITH_OPTION2=no" in the directory at the top of the external project's source tree. This is one of a few dozen external projects we use. Most of them fit the model of 'configure; make; make install' but a good third don't and this is one that I thought would be easy.
If I try to have the make command invoked like this:
ExternalProject_Add(build-example
PREFIX "${CMAKE_CURRENT_BINARY_DIR}/example"
DEPENDS ""
SOURCE_DIR "${PROJECT_TOPDIR}/External/example"
CONFIGURE_COMMAND ""
BUILD_COMMAND COMMAND make WITH_OPTION1=no WITH_OPTION2=no
INSTALL_COMMAND "")
The resulting make step is done from the wrong directory and therefore the Makefile is not found.
If I add a -C option to the make command it seems to use the right directory, but it ignores the WITH_OPTION stuff. That doesn't compile properly, because those features use things I don't want to provide, and if it did work, I still don't want those features.
If I then add quotes around the entire desired make command, it goes wrong. Apparently the command is passed to 'sh' in such a way that sh fails.
If I use a mechanism to pass the command into a 'configure-file' step and invoke that file from the BUILD_COMMAND, then CMake actually tries to use a broken CMakeLists.txt file that's in the external project, and I wonder what makes CMake think that it should do so.
I just want to invoke the makefile properly, using CMake to organize that build within the dozens of other builds that have to be done to build the complete project.
I have a CMake configuration file building two libraries:
a third-party library (here called ThirdPartyLib) containing a real-time OS / board support package from a supplier. It is built outside CMake using the autotools toolchain.
an extended version of the former library (here called ExtendedThirdPartyLib)
Unfortunately, some source code that I need (various tools) are not built in the ordinary build script for (1). Since I don't want to mess with the suppliers build script I want to add another library (2), building the missing files and thus extending the library from the supplier.
I want to able to do something like this in CMakeFiles.txt:
cmake_minimum_required(VERSION 3.2)
project(bsp)
include(ExternalProject)
ExternalProject_Add(
ThirdPartyLib
URL <http://some.url/bsp.tar.bz2
BUILD_COMMAND make -C ../external/ThirdPartyLib/src
)
set_target_properties(ThirdPartyLib PROPERTIES EXCLUDE_FROM_ALL TRUE)
add_library(ExtendedThirdPartyLib
${CMAKE_CURRENT_BINARY_DIR}/some/path/missing_file1.c
${CMAKE_CURRENT_BINARY_DIR}/some/path/missing_file2.c
)
add_dependencies(ExtendedThirdPartyLib ThirdPartyLib)
target_include_directories(ExtendedThirdPartyLib PUBLIC
${CMAKE_CURRENT_BINARY_DIR}/some/path/include
)
target_link_libraries(ExtendedThirdPartyLib ThirdPartyLib)
The problem here is that the path to missing_file1.c and missing_file2.c are not valid when CMake is generating the build files (they are extracted from the tarball from the supplier). CMake exits with an error output saying: "Cannot find source file".
Is there a neat way to make this work? I.e. is it possible to convince CMake that certain non-existant input files will exist when building of the library begins? Or is there any other recommended way to solve this issue?
(I have temporary made local copies of the files I need to build from the suppliers tarball, but that is of course not a good solution. If those files are changed in future versions of the suppliers package and I forget to overwrite my local copies it could be a horrible mess...
Another "solution" would be to create a small makefile outside CMake and use another ExternalProject_Add in the CMakeFiles.txt somehow. But that's not a good solution either, e.g. if compile and linker flags are modified I need to remember to change the makefile too.)
Personally, I dislike the ExternalProject_Add command, because it does way too many things for my taste, but I've digressed.
What if you do something like this, where bar is simulating your ExtendedThirdPartyLib target, since it depends on generated files
cmake_minimum_required(VERSION 3.11)
project(lol C)
set(SOURCES lol.c) # only this file exists
add_library(lol ${SOURCES})
set(FOO_FILES "foo1.c" "foo2.c")
add_custom_command(OUTPUT ${FOO_FILES}
COMMAND ${CMAKE_COMMAND} -E touch ${FOO_FILES}
WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}"
COMMENT "Creating ${FOO_FILES}"
VERBATIM)
add_custom_target(foo DEPENDS ${FOO_FILES})
add_library(bar ${FOO_FILES})
add_dependencies(bar foo)
target_link_libraries(lol bar)
The whole approach hinges on the fact that the method, where produced/generated files are procured, is explicitly defined via the custom command and associated custom target.
You should modify the custom command to extract the required files (e.g. could even call some external script) from the tarball (which might require downloading with curl or something similar).
What I wanted to do is call
add_subdirectory(ext/oglplus)
and be done with it. Unfortunately it is not that simple. There is a huge buildscript which detects various opengl settings. So I tried the following
ExternalProject_Add(liboglplus
SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ext/oglplus
CONFIGURE_COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/ext/oglplus/configure.py --use-glew
BUILD_COMMAND ${MAKE})
The problem that I have is don't really want to build it like that. It also doesn't build correctly because for some reason it wants to install the library and because there is no install target it will abort the compilation.
But the build script is calling cmake under the hood.
So what I want to do is to tell cmake to use "cofigure.py" instead of "cmake .." and then use it like any other cmake library.
Is this possible?
I used to call Linux Kernel KBuild from CMake using
ADD_CUSTOM_COMMAND() and ADD_CUSTOM_TARGET()
This way you can run arbitrary commands (like your config.py) and use the output.
First setup the command with all command-line options as CMake-variables, in tou case this would be calling the config.py script ${CMAKE_CURRENT_SOURCE_DIR}/ext/oglplus/.
Instead of encoding the Path to your script in the command (adding ext/oglplus) I think it may be better adding WORKING_DIRECTORY to the custom command:
add_custom_command
SET(KBUILD_CMD ${CMAKE_MAKE_PROGRAM}
-C ${KERNEL_BUILD_DIR}
CROSS_COMPILE=${CROSS_COMPILE} ARCH=${ARCH}
EXTRA_CFLAGS=${KBUILD_EXTRA_CFLAGS}
INSTALL_MOD_PATH=${INSTALL_MOD_PATH}
M=${CMAKE_CURRENT_SOURCE_DIR}
KBUILD_EXTRA_SYMBOLS=${depends_module_ksyms}
)
Add a custom command that calls your build-script and creates a file in the CMAKE_CURRENT_BINARY_DIRECTORY (note the second COMMAND to touch a file)
ADD_CUSTOM_COMMAND(
OUTPUT ${module_name}.built
COMMAND ${KBUILD_CMD} modules
COMMAND cmake -E touch ${module_name}.built
COMMENT "Kernel make modules ${module_name}"
VERBATIM
)
Add a custom target, its always out of date, but if you want it to be called automatically add ALL otherwise you have to explicityly call make module_build, I guess this is what you want.
ADD_CUSTOM_TARGET("${module_name}_build" ALL
DEPENDS ${depends_module_ksyms}
${CMAKE_CURRENT_BINARY_DIR}/${module_name}.built
COMMENT "Building Kernel Module ${module_name}"
)
I'm building a very light-weight library/wrapper for OpenGL and I've run into a little problem. Let's say I have a directory structure that looks sort of like this:
GraphicsProject
|GraphicsApp
||main.cpp
|GraphicsLib
||include
|||fileA.h
|||fileB.h
||library
|||fileA.cpp
|||fileB.cpp
||shaders
|||shader1.txt
|||shader2.txt
|| build
||| bunch of build stuff
What is the best way to get the path to shader1.txt at runtime? Or else, make it such that the path will not change no matter who is using this project or where it is located on a user's machine?
Some options I've considered:
1) Get the current working directory and use that path to work my way up to where I need to be. My main concern with this solution is that I'm not sure how much the current directory will change based on how the user builds the project or other factors out of my control. It also doesn't feel very elegant.
2) Store the source code for the shaders as char arrays/strings in a .h file that is in the include directory. This seems like a better solution, except that it would make writing the shaders slightly more cumbersome.
Is there a standard way of doing this? I'm using CMake to build the project, if that changes anything.
I'm assuming you're talking about making the "shaders" folder available to other devs who are building your project, since if you meant end-users (which would involve installing the components) you wouldn't be talking about build folders.
I think the simplest way to provide a fixed location to the shaders folder at runtime is to copy it from your source tree to your build tree. In this way, other devs can place their root build folder anywhere outside your project (or even inside if they want) and the app will still have a single fixed relative path to deal with when accessing the copied shaders folder.
There are other options in case you don't want to copy (e.g. you could have CMake write a config file to the build tree; the config file could specify the path to the shaders folder) but I think they're more complex and probably more fragile. Regardless, I think the crux is to copy info from the source tree to the build tree at configure-time (when CMake executes), so that the runtime code doesn't involve a difficult search for the potentially very distant source tree.
An example root CMakeLists.txt would be:
cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
project(example)
add_executable(GraphicsApp GraphicsApp/main.cpp)
add_library(GraphicsLib
GraphicsLib/library/fileA.cpp
GraphicsLib/library/fileB.cpp
GraphicsLib/include/fileA.h
GraphicsLib/include/fileB.h
GraphicsLib/shaders/shader1.txt
GraphicsLib/shaders/shader2.txt
)
include_directories(GraphicsLib/include)
target_link_libraries(GraphicsApp GraphicsLib)
add_custom_command(TARGET GraphicsApp POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_SOURCE_DIR}/GraphicsLib/shaders
$<TARGET_FILE_DIR:GraphicsApp>/shaders)
To expand a little on the add_custom_command call, this basically causes the "shaders" subdirectory to be copied to the folder where GraphicsApp will be built to. The command executes any time GraphicsApp is built. If GraphicsApp is built and up to date and you try and rebuild it, the custom command won't execute.
The custom command actually executes
cmake -E copy_directory <path to shaders source> <path to shaders copy>
making use of CMake's -E cross-platform command mode.
The "destination" part of the command (the "copy to" location) uses a generator expression to deduce the location where GraphicsApp will be built to: $<TARGET_FILE_DIR:GraphicsApp>. This is probably the most robust way of achieving that aim; it will be correct regardless of config type (where e.g. MSVC inserts a "Debug/" or "Release/" folder to the build path).
So this hopefully gets you most of the way to your aim. I imagine you still have to get the full path to the running exe to then deduce the full path to the copied shaders folder. However, this should be much more simple and robust than searching from the current working directory. Even calculating the current working dir is non-trivial.
I'm trying to include an external library in a build environment that uses CMake. I'm not trying to install it on the local system (in fact I'd rather not do that, I don't want /usr/local clogged up with all kinds of libraries); I'd just like to have the resulting libxml2.a available for linking with my executable. I can build it fine with the following in CMakeLists.txt:
set (LIBXML_PATH ${MY_SOURCE_DIR}/libxml2-2.9.1)
add_custom_target (build_libxml ALL
COMMENT "Building libxml"
COMMAND ./configure --prefix=/tmp
COMMAND make
WORKING_DIRECTORY ${LIBXML_PATH}
)
But I'm still having trouble with the following:
1) Is this the right approach in the first place, for the general purpose of getting libraries built with configure and make into a CMake environment?
2) How do I get the resulting library (i.e. libxml2.a) under my build output directory?
3) How can I link to that library for my executable builds?
I tried a fiddly solution with
ADD_LIBRARY( xml2 STATIC libxml2.a )
but it seems like there must be a better way than hauling a whole library's contents into… a library.
Thanks.
You need to make it clearer to CMake what is going on here. All it can see now is that you have some custom command that it will run every time. Instead of using add_custom_target with COMMAND, I've found it better to use add_custom_command.
Something like this:
set (LIBXML_PATH ${MY_SOURCE_DIR}/libxml2-2.9.1)
add_custom_command(
OUTPUT libxml2.a
COMMENT "Building libxml"
COMMAND ./configure --prefix=/tmp
COMMAND make
WORKING_DIRECTORY ${LIBXML_PATH}
)
target_link_libraries(your-program libxml2.a)
By doing it this way, CMake can understand that your custom command's essential product is libxml2.a, and when CMake sees something depending on that, it will run the command (if the library doesn't exist already).