From a CI perspective, I want to supply custom args to ctest (address, port, ..).
Right now, ctest is functional into my project. I am able to do:
cmake ..
make
make test
And everything works fine. But I wish to run the following:
cmake ..
make
make test --port 9090
And have "port" available into my tests. But I don't know how to handle it with cmake/make.
For information, I'm using gtest and the executable build with make is already able to handle my args. I'm only stuck to give the arguments through cmake/make.
Related
I'm trying to learn several things at once (arguably my first problem...), namely: unit testing with Catch2 and building with CMake.
In the course of my investigations, CTest appeared on the radar as a pre-baked way of managing tests within CMake, and seems to 'support' Catch2.
While things seem to build okay, I can't run my tests as automatically as I'd hope.
Specifically, I have a source tree, which at some point contains the library I'm testing, and I'd like to be able to sit at the top of the tree and execute some sort of 'run my tests' command (and ideally run them as part of the full build, but that's for another day).
So here's my CMakeLists.txt file (L:\scratch\shared\testeroolib\CMakeLists.txt) for the library of interest:
cmake_minimum_required(VERSION 3.5)
project(testeroolib)
add_library(${PROJECT_NAME} STATIC src/testeroolib.cpp)
target_include_directories(${PROJECT_NAME} PUBLIC include)
set(PROJECT_TEST ${PROJECT_NAME}_test)
add_executable(${PROJECT_TEST} test/catch2_main.cpp)
target_link_libraries(${PROJECT_TEST} PRIVATE Catch)
target_link_libraries(${PROJECT_TEST} PRIVATE ${PROJECT_NAME})
enable_testing()
add_test(NAME TesterooLibTest COMMAND ${PROJECT_TEST})
If I do the naive thing and run ctest from the same location I run cmake, I get:
L:\scratch>ctest
*********************************
No test configuration file found!
*********************************
...
or
L:\scratch>ctest .
Test project L:/scratch
No tests were found!!!
From what I've read elsewhere, make test would do the trick with GCC and friends, but I'm using VS.
So here, the advice seems to be that I should use a build target of ALL_TESTS but that doesn't do the trick for me.
L:\scratch>cmake --build BUILD --target ALL_TESTS
...
MSBUILD : error MSB1009: Project file does not exist.
Switch: ALL_TESTS.vcxproj
Of course, I can just run the test:
L:\scratch>BUILD\shared\testeroolib\Debug\testeroolib_test.exe
===============================================================================
All tests passed (1 assertion in 1 test case)
I'm hoping I've made some tiny snafu, but there is every chance I've got completely the wrong end of the stick here!
I believe I've found the (two-part) answer.
The first part is that it's no good running ctest from the top level, you need to run it from the build folder. With hindsight, that's pretty obvious :(
cmake -S . -B BUILD
cmake --build BUILD
cd BUILD
ctest
The less obvious part I found in this answer: https://stackoverflow.com/a/13551858/11603085.
Namely, the enable_testing() call needs to be in the top-level CMakeLists.txt, not the one further down that actually builds the library.
I believe the root cause of your problem is the missing Debug/Release configuration info which cmake needs when you configured using Visual Studio. Try:
ctest -C Debug
for example.
I'm trying to build a multi-dist executable using Travis CI which will put the built executables on github.
I want the name to be somename.os.arch.
When I build locally via command line, I use the -o param and the env vars $GOOS & $GOARCH e.g.: go build -o somename.$GOOS.$GOARCH
However, I cannot specify this for TravisCI using their build_args as other steps fail (not understanding -o flag)
Is there a Go build config file I can create to set the build output name?
Override script. If you mean gobuild_args instead of build_args, it is only passed to the default command go test ./..., so I don't think it would work.
I'm trying to port a *nix, CMake-based project to Windows. One header file needed by the main library is generated by a custom program, so the CMakeLists.txt file contains something like this:
add_executable(TableGenerator "TableGenerator.cpp")
target_link_libraries(TableGenerator ${LibFoo_LIBRARY})
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND TableGenerator "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
DEPENDS TableGenerator)
An important detail is that TableGenerator uses the external shared library LibFoo. For example under Linux, everything works fine, because libfoo.so is installed in one of the system library directories like /usr/local/lib, or CMake even sets the rpath attribute in the executable, saying where exactly to find the library.
On Windows, however, these kind of libraries are usually not installed into the system but are rather just extracted or compiled into some arbitrary directory in or near the build tree. In order for TableGenerator to run, the foo.dll would need to be available in or copied to one of the Dynamic-Link Library Search Order paths (say %WINDIR%\System32 or the build output directory for TableGenerator), which is not desirable.
How can I set the PATH environment variable for the custom command, i.e. to be used not during the CMake run but during the actual custom build step runtime?
While still doing my research in order to ask the question properly, I have found three solutions. Considering how hard it was to find this information, I decided to post the question and answer here anyway.
1. Using global variable CMAKE_MSVCIDE_RUN_PATH
There is a special variable dedicated to solving this exact problem – CMAKE_MSVCIDE_RUN_PATH. If set, it results in a line like this being added to the custom build step script:
set PATH=<CMAKE_MSVCIDE_RUN_PATH>;%PATH%
So all that's needed then is something like this at a good place:
set(CMAKE_MSVCIDE_RUN_PATH ${LibFoo_RUNTIME_LIBRARY_DIRS})
I have originally noticed this variable only in CMake sources, because it used to be undocumented until CMake 3.10. So you might not be able to find it in documentation for older versions of CMake, but don't worry, it's been supported since 2006.
Advantages:
▪ Can be enabled at one central place
▪ No change at all in any of the add_custom_command() commands elsewhere is needed
▪ Only the path itself is set, no batch commands need to be written explicitly
▪ The obvious choice with clear name and intent
Disadvantages:
▪ Global for the whole CMake project and all custom commands
▪ Works with the "Visual Studio 9 2008" and above generators only
2. Setting the PATH explicitly using two COMMAND parameters
The script being generated for the custom build step in Visual Studio contains some prologue, then the commands themselves and then some epilogue. Wouldn't it be possible to simply add set PATH=... before the real command through another COMMAND parameter?
The documentation for add_custom_command() says:
COMMAND
Specify the command-line(s) to execute at build time. If more than one COMMAND is specified they will be executed in order, but not necessarily composed into a stateful shell or batch script.
So no, that's not guaranteed to be possible. But the Visual Studio project generator actually does it like this, i.e. the individual commands are just appended one after another, so the following does the job:
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND set "PATH=${LibFoo_RUNTIME_LIBRARY_DIRS};%PATH%"
COMMAND TableGenerator "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
DEPENDS TableGenerator)
Advantages:
▪ The PATH can be changed for each custom command explicitly
Disadvantages:
▪ Relies on an undocumented behavior of the generator
▪ It's necessary to rewrite the whole command for Windows and keep both versions in sync
▪ Each custom command must be changed explicitly
3. Using file(GENERATE ...) to create a custom script
The documentation for add_custom_command() quoted above continues:
To run a full script, use the configure_file() command or the file(GENERATE) command to create it, and then specify a COMMAND to launch it.
This is a bit messy because of the additional temporary files and commands:
file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/RunTableGenerator.cmd"
CONTENT "set PATH=${LibFoo_RUNTIME_LIBRARY_DIRS};%PATH%
%1 ${CMAKE_CURRENT_BINARY_DIR}/Table.h")
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND "${CMAKE_CURRENT_BINARY_DIR}/RunTableGenerator.cmd" "$<TARGET_FILE:TableGenerator>"
DEPENDS TableGenerator)
Notice the awkward way of sending the path to the executable as an argument. This is necessary because the script is writen once, but TableGenerator might be in different locations for different configurations (debug and release). If the generator expression was used directly in the content, a CMake error would be printed and the project would not build correctly for all but one configuration.
Advantages:
▪ The PATH can be changed for each custom command explicitly
▪ A fully documented and recommended solution
Disadvantages:
▪ Very noisy in the CMakefiles
▪ It's necessary to rewrite the whole command for Windows and keep both versions in sync
▪ Each custom command must be changed explicitly
4. Launch the custom command through CMake wrapper
See the other answer below contributed by Dvir Yitzchaki.
I had personally settled on the solution #1 because it was clean and simple, even before it got properly documented and supported by CMake in version 3.10. It should be the best way forward for you as well, unless you need to do something even more special.
There is another way besides what Yirkha wrote and that is to run the executable through cmake and use cmake's -E option to set the environment.
So in your case it will be:
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND ${CMAKE_COMMAND} -E env "PATH=${LibFoo_RUNTIME_LIBRARY_DIRS}" $<TARGET_FILE:TableGenerator> "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
DEPENDS TableGenerator)
See http://www.cmake.org/pipermail/cmake/2006-March/008522.html for details.
I have a number of unit tests written for my project, executed with CTest. I would like to integrate the results into my TeamCity build. I've downloaded and set up the plugin for my testing framework (Boost Test).
The problem that I have run into is that the tests run with CTest output to Testing/Temporary/LastTest.log, whereas TeamCity is trying to read the results from standard out. To get around this, my testing step is.
make test
cat Testing/Temporary/LastTest.log
which works, but feels like a hack.
Is there any way to get TeamCity to read from this file in addition to standard out? Alternatively, is there any way to tell ctest to output to standard out in addition to this LastTest.log file?
This question is similar, but I would like it to work for all output rather than just on failure: CMake: setting an environmental variable for ctest (or otherwise getting failed test output from ctest/make test automatically)
Teamcity has additional build features which allow to process CTest reports. I am not sure if it'll work or not but you could try adding an additional build feature in your build step to read CTest report.
I've got the following piece of script in my CMake file:
CONFIGURE_FILE(
${CMAKE_CURRENT_SOURCE_DIR}/version.hpp.cmake
${CMAKE_CURRENT_SOURCE_DIR}/version.hpp
)
But it's only run after executing cmake, not make. Is it possible to create the version.hpp file after each make?
Here is the content of version.hpp.cmake:
#ifndef _VERSION_HPP_
#define _VERSION_HPP_
#define MAJOR_VERSION "${MAJOR}"
#define MINOR_VERSION "${MINOR}"
#define PATCH_VERSION "${PATCH}"
#define RELEASE_VERSION "${RELEASE}"
#endif //_VERSION_HPP_
The MAJOR, MINOR, PATCH and RELEASE variables have been defined in the CMakeLists.txt file.
P.S. This post is apparently related to my question, but I can't get a grasp of it.
The problem is that configure_file is supposed to run at configure time, that is when you run cmake, instead of compile time, which is when you run make. There is no easy way around this.
The problem is that the information written by configure_file is dependent on variables from the CMake build environment. Changes to those variables cannot be detected without running CMake again. If you have that information mirrored somewhere else, you can use a custom command to extract it and perform the code generation for you, as Peter's answer suggested.
The approach suggested in the post from the CMake mailing list that you linked in your answer is based on a two-phase CMake run: The outer CMake project (which is run only once) adds a custom build step for building the inner CMake project (which is then run with every make) where the configure_file is performed. The underlying idea is the same as with Peter's answer, only instead of a Python script you use a CMake script for generating the file.
My personal recommendation: For a simple problem as a version header, I would not bother with such a complicated approach. Simply generate the file to your BINARY_DIR (not to your project dir, as you currently do! you want to retain the ability to do several out-of-source builds from the same source) and assume that it will be there for compilation. If a user is brave enough to mess with the generated files there, they can be expected to re-run CMake on their own.
So I accidentally stumbled across this, I know it is probably too late, but calling configure is possible an exactly how I do this with mercurial versions.
The trick requires a lot of different tools, and I don't have time to formulate into a good answer atm, but ask questions and I'll fill it in when I have time.
tool 1: calling exec_program to extract the revision information (this is really easy with mercurial)
exec_program(hg ${PROJECT_SOURCE_DIR} ARGS "id" "-i" OUTPUT_VARIABLE OUTPUT_VARIABLE ${PROJECT_NAME}_HG_HASH_CODE)
I'm probably doing something more complicated than you care about here, but the essential bit is hg which you'll replace with whatever version control you are using, ${PROJECT_SOURCE_DIR} which you'll set to whatever executing directory you want, and fill in the custom args.
I put all of the version extraction into a single macro (ReadProjectRevisionStatus()).
The next step is to make a an entirely different CMake file that calls ReadProjectRevisionStatus() and then CONFIGURE_FILE. This file will assume that all the correct values are set when you come into it. In my case, I store the location of this file into ${CONFIG_FILE_LOC}.
The final step is to add a custom target that will call this script. For example:
ADD_CUSTOM_TARGET(${PROJECT_NAME}_HG_VERSION_CONFIG
COMMAND ${CMAKE_COMMAND}
ARGS -DPROJECT_SOURCE_DIR=${PROJECT_SOURCE_DIR}
-DPROJECT_BINARY_DIR=${PROJECT_BINARY_DIR}
-DPROJECT_NAME=${PROJECT_NAME}
-DCMAKE_MODULE_PATH=${CMAKE_MODULE_PATH}
"-D${PROJECT_NAME}_HG_CONFIG_FILE_IN=\"${${PROJECT_NAME}_HG_CONFIG_FILE_IN}\""
"-D${PROJECT_NAME}_HG_CONFIG_FILE_OUT=\"${${PROJECT_NAME}_HG_CONFIG_FILE_OUT}\""
${ARGN}
-P ${CONFIG_FILE_LOC})
One of the beauties of doing it this way is that custom target call can still be called outside of a cmake build system, which I've done on a couple of projects, which a bash call similar to:
cmake -D PROJECT_SOURCE_DIR=$sourcedir -DPROJECT_BINARY_DIR=$sourcedir -DPROJECT_NAME=uControl -DCMAKE_MODULE_PATH=$sourcedir -DuControl_HG_CONFIG_FILE_IN=$sourcedir/tsi_software_version.h.in -DuControl_HG_CONFIG_FILE_OUT=$sourcedir/tsi_software_version.h -P $sourcedir/ConfigureHGVersion.cmake
One possibity is to generate version.hpp from Python and use ADD_CUSTOM_TARGET
... find python ...
ADD_CUSTOM_TARGET(gen_version ALL ${PYTHON_EXECUTABLE} gen_version.py)
SET_SOURCE_FILES_PROPERTIES(version.hpp PROPERTIES GENERATED 1)
... link gen_version to your library/executable ...