How to use CPACK_RPM_POST_INSTALL_SCRIPT_FILE? - cmake

Here is the setup I tried using CMake 2.8.2 to reproduce the problem:
/test.sh:
/CMakeLists.txt:
cmake_minimum_required(VERSION 2.8)
SET(CPACK_PACKAGE_NAME test)
SET(CPACK_PACKAGE_VERSION 1.0)
LIST(APPEND CPACK_GENERATOR RPM)
SET(CPACK_RPM_POST_INSTALL_SCRIPT_FILE "test.sh")
INCLUDE(CPack)
then:
mkdir build && cd build && cmake .. && make package
Results:
CPackRPM:Warning: CPACK_RPM_POST_INSTALL_SCRIPT_FILE does not exists - ignoring
How to make the build system aware of my file test.sh ?

You need to use absolute path:
SET(CPACK_RPM_POST_INSTALL_SCRIPT_FILE "${CMAKE_CURRENT_SOURCE_DIR}/test.sh")
This is needed because CPackRPM needs the absolute path of the file as CPack does not know that test.sh is relative to source tree.

Related

How do I get cmake to halt processing on error [duplicate]

I want to disallow people from cluttering our source tree with generated CMake files... and, more importantly, disallow them from stepping on existing Makefiles that are not part of the same build process we're using CMake for. (best not to ask)
The way I have come up with to do this is to have a few lines at the top of my CMakeLists.txt, as follows:
if("${PROJECT_SOURCE_DIR}" STREQUAL "${PROJECT_BINARY_DIR}")
message(SEND_ERROR "In-source builds are not allowed.")
endif("${PROJECT_SOURCE_DIR}" STREQUAL "${PROJECT_BINARY_DIR}")
However, doing it this way seems too verbose. Additionally, if I try an in-source build it still creates the the CMakeFiles/ directory, and the CMakeCache.txt file in the source tree before the error is thrown.
Am I missing a better way to do this?
CMake has two undocumented options:
CMAKE_DISABLE_SOURCE_CHANGES and CMAKE_DISABLE_IN_SOURCE_BUILD
cmake_minimum_required (VERSION 2.8)
# add this options before PROJECT keyword
set(CMAKE_DISABLE_SOURCE_CHANGES ON)
set(CMAKE_DISABLE_IN_SOURCE_BUILD ON)
project (HELLO)
add_executable (hello hello.cxx)
-
andrew#manchester:~/src% cmake .
CMake Error at /usr/local/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:160 (FILE):
file attempted to write a file: /home/andrew/src/CMakeFiles/CMakeOutput.log
into a source directory.
/home/selivanov/cmake-2.8.8/Source/cmMakefile.cxx
bool cmMakefile::CanIWriteThisFile(const char* fileName)
{
if ( !this->IsOn("CMAKE_DISABLE_SOURCE_CHANGES") )
{
return true;
}
// If we are doing an in-source build, than the test will always fail
if ( cmSystemTools::SameFile(this->GetHomeDirectory(),
this->GetHomeOutputDirectory()) )
{
if ( this->IsOn("CMAKE_DISABLE_IN_SOURCE_BUILD") )
{
return false;
}
return true;
}
// Check if this is subdirectory of the source tree but not a
// subdirectory of a build tree
if ( cmSystemTools::IsSubDirectory(fileName,
this->GetHomeDirectory()) &&
!cmSystemTools::IsSubDirectory(fileName,
this->GetHomeOutputDirectory()) )
{
return false;
}
return true;
}
Include a function like this one. It is similar to what you do with these differences:
It is encapsulated in a function, which is called when you include the PreventInSourceBuilds.cmake module. Your main CMakeLists.txt must include it:
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_CURRENT_SOURCE_DIR}/CMake)
include(PreventInSourceBuilds)
It uses get_filename_component() with REALPATH parameter that resolves symlinks before comparing the paths.
In case the github link changes, here's the module source code (which should be placed in a PreventInSouceBuilds.cmake, in a directory called CMake, in the above example):
#
# This function will prevent in-source builds
function(AssureOutOfSourceBuilds)
# make sure the user doesn't play dirty with symlinks
get_filename_component(srcdir "${CMAKE_SOURCE_DIR}" REALPATH)
get_filename_component(bindir "${CMAKE_BINARY_DIR}" REALPATH)
# disallow in-source builds
if("${srcdir}" STREQUAL "${bindir}")
message("######################################################")
message("# ITK should not be configured & built in the ITK source directory")
message("# You must run cmake in a build directory.")
message("# For example:")
message("# mkdir ITK-Sandbox ; cd ITK-sandbox")
message("# git clone http://itk.org/ITK.git # or download & unpack the source tarball")
message("# mkdir ITK-build")
message("# this will create the following directory structure")
message("#")
message("# ITK-Sandbox")
message("# +--ITK")
message("# +--ITK-build")
message("#")
message("# Then you can proceed to configure and build")
message("# by using the following commands")
message("#")
message("# cd ITK-build")
message("# cmake ../ITK # or ccmake, or cmake-gui ")
message("# make")
message("#")
message("# NOTE: Given that you already tried to make an in-source build")
message("# CMake have already created several files & directories")
message("# in your source tree. run 'git status' to find them and")
message("# remove them by doing:")
message("#")
message("# cd ITK-Sandbox/ITK")
message("# git clean -n -d")
message("# git clean -f -d")
message("# git checkout --")
message("#")
message("######################################################")
message(FATAL_ERROR "Quitting configuration")
endif()
endfunction()
AssureOutOfSourceBuilds()
I have a cmake() shell function in my .bashrc/.zshrc similar to this one:
function cmake() {
# Don't invoke cmake from the top-of-tree
if [ -e "CMakeLists.txt" ]
then
echo "CMakeLists.txt file present, cowardly refusing to invoke cmake..."
else
/usr/bin/cmake $*
fi
}
I prefer this low ceremony solution. It got rid of my colleagues' biggest complaint when we switched to CMake, but it doesn't prevent people who really want to do an in-source/top-of-tree build from doing so—they can just invoke /usr/bin/cmake directly (or not use the wrapper function at all). And it's stupid simple.
I think I like your way. The cmake mailing list does a good job at answering these types of questions.
As a side note: you could create a "cmake" executable file in the directory which fails. Depending on whether or not "." is in their path (on linux). You could even symlink /bin/false.
In windows, I am not sure if a file in your current directory is found first or not.
You can configure your .bashrc file like this one
Look at the functions cmakekde and kdebuild. Set BUILD and SRC env. variables and edit these functions according to your needs. This will build only in buildDir rather than srcDir
Just make the directory read-only by the people/processes doing the builds. Have a separate process that checks out to the directory from source control (you are using source control, right?), then makes it read-only.
For those on Linux:
add to top-level CMakeLists.txt:
set(CMAKE_DISABLE_IN_SOURCE_BUILD ON)
create a file 'dotme' in your top-level or add to your .bashrc (globally):
#!/bin/bash
cmk() { if [ ! -e $1/CMakeLists.txt ] || ! grep -q "set(CMAKE_DISABLE_IN_SOURCE_BUILD ON)" $1/CMakeLists.txt;then /usr/bin/cmake $*;else echo "CMAKE_DISABLE_IN_SOURCE_BUILD ON";fi }
alias cmake=cmk
now run:
. ./dotme
when you try to run cmake in the top-level source tree:
$ cmake .
CMAKE_DISABLE_IN_SOURCE_BUILD ON
No CMakeFiles/ or CMakeCache.txt gets generated.
When doing out-of-source build and you need to run cmake first time just call the actual executable:
$ cd build
$ /usr/bin/cmake ..
This is still the best answer for my purposes:
project(myproject)
if(PROJECT_SOURCE_DIR STREQUAL PROJECT_BINARY_DIR)
message(FATAL_ERROR "In-source builds are not allowed")
endif()
or allow the build, but show a warning message:
if(PROJECT_SOURCE_DIR STREQUAL PROJECT_BINARY_DIR)
message(WARNING "In-source builds are not recommended")
endif()
However, there does not appear to be a simple way to avoid CMakeFiles/ and CMakeCache.txt being created in the source directory.

Is it possible to determine whether CMake install(CODE) is called from the "install" or "package" stage?

I'm using CMake v3.21.0 to invoke Qt's windeployqt during the install stage by the means of the install(CODE) command as follows:
install(
CODE "
execute_process(
COMMAND \"${CMAKE_COMMAND}\" -E
env PATH=\"${windeployqt_ROOT_DIR}\"
\"${windeployqt_EXECUTABLE}\"
# TODO(2021-08-25 by wolters): This is a different path when CPack is`
# used. How to check for this case and obtain the correct output path?
--dir \"${CMAKE_INSTALL_PREFIX}/${args_INSTALL_SUFFIX}\"
--no-quick-import
--no-system-d3d-compiler
--no-virtualkeyboard
--no-compiler-runtime
--no-webkit2
--no-angle
--no-opengl-sw
--verbose 0
\"\$<TARGET_FILE:${args_TARGET}>\"
)
"
COMPONENT runtime
)
This works fine if installing the project:
cmake --build . --config RelWithDebInfo --target install
But when creating a CPack package the files created by windeployqt are not part of the package (ZIP in this case):
cpack -G ZIP -C RelWithDebInfo -D CPACK_COMPONENTS_ALL="runtime"
I know that the issue is the usage of ${CMAKE_INSTALL_PREFIX} in the CODE.
For the install target this is correct.
For the package target this is not correct. Instead the build directory for the current CPack generator should be used, e.g. ${CMAKE_CURRENT_BINARY_DIR}/_CPack_Packages/win64/ZIP/${CPACK_PACKAGE_FILE_NAME}.
My questions are:
Is there a way to differentiate between install and package target in the CODE section? (pseudo-code: if(CMAKE_IS_PACKAGING))
If there is a way: Is it possible to obtain or dynamically build the directory path to the actual CPack temporary "install" directory?
If both problems can be solved the files generated by windeployqt should be part of the packages generated by CPack.
The variable CMAKE_INSTALL_PREFIX should not be expanded in the CMakeLists.txt, as you are doing. Its actual value at invocation time is available inside the install(CODE) fragments.
Consider the following snippet:
cmake_minimum_required(VERSION 3.21)
project(test NONE)
install(CODE [[message(STATUS "HERE: ${CMAKE_INSTALL_PREFIX}")]])
Note that [[ ... ]] escapes variable expansions (you could also use backslashes). Now if you configure this project with -DCMAKE_INSTALL_PREFIX=/tmp/install, you'll see the message print as you expect.
$ cmake -S . -B build -DCMAKE_INSTALL_PREFIX=/tmp/install
-- Configuring done
-- Generating done
-- Build files have been written to: /home/alex/test/build
$ cmake --build build/ --target install
[0/1] Install the project...
-- Install configuration: ""
-- HERE: /tmp/install
If you now run the install script again without reconfiguring or rebuilding, it will still work:
$ cmake --install build/ --prefix /tmp/other-prefix
-- Install configuration: ""
-- HERE: /tmp/other-prefix
This is how CPack runs your install rules. It does not use the configuration-time value of CMAKE_INSTALL_PREFIX. It expects your project to be relocatable (i.e. bug-free).

How to use CMake to build sources with ghdl as custom target?

I would like to build VHDL sources with CMake. For this I have a directory structure:
<root>
- CMakeLists.txt
- src/CMakeLists.txt
- src/mymodule.vhdl
- build
Inside the root CMakeLists.txt I have:
cmake_minimum_required(VERSION 3.12)
project(vhdlsdb LANGUAGES NONE)
add_subdirectory(src)
In the src/CMakeLists.txt I have:
set(filelist mymodule.vhdl )
add_custom_target(vhdlize COMMAND ghdl -a ${filelist})
However, when I run cd build && cmake .. -GNinja && cmake --build . --target vhdlize I get:
error: cannot open mymodule
C:\Users\pm\git\GHDL\0.36-mingw64-llvm\bin\ghdl.exe: compilation error
How can I tell CMake to copy or look for the sources in the src folder?

Using google tests with CMake/Ctest with the new command gtest_discover_tests

I am trying to use googletest with CMake/Ctest. I have several sources files for my tests (each one containing many TEST/TEST_F/... commands) which are located in several directories. I want that the tests related to a given source are executed in the same directory as their source file. Also, I prefer that the build process of a test source file is a test by itself. So I made something like:
file(GLOB_RECURSE test_srcs
RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}
"tests/*.cpp")
foreach(test_src ${test_srcs})
get_filename_component(test_dir ${test_src} DIRECTORY)
get_filename_component(test_exe ${test_src} )NAME_WE)
add_executable(${test_exe} EXCLUDE_FROM_ALL tests/gtest_main.cpp ${test_src})
set_target_properties(${test_exe}
PROPERTIES RUNTIME_OUTPUT_DIRECTORY ${test_dir}
)
target_link_libraries(${test_exe} gtest)
add_test(NAME build_${test_exe} COMMAND "${CMAKE_COMMAND}" --build ${CMAKE_BINARY_DIR} --target ${test_exe})
set_tests_properties(build_${test_exe} PROPERTIES FIXTURES_SETUP ${test_exe})
gtest_discover_tests(${test_exe}
TEST_LIST list
WORKING_DIRECTORY ${test_dir}
PROPERTIES DEPENDS build_${test_exe}
PROPERTIES FIXTURES_REQUIRED ${test_exe}
)
endforeach()
But it seems that the dependencies I am trying to declare between the tests are not taken into account: the build of the tests does not necessarily occurs before the execution of the underlying tests...
If I use the old gtest_add_tests as in the following instead of gtest_discover_tests, it works:
gtest_add_tests(
TARGET ${test_exe}
SOURCES ${test_src}
WORKING_DIRECTORY ${test_dir}
TEST_LIST tlist
)
set_tests_properties(${tlist} PROPERTIES FIXTURES_REQUIRED ${test_exe})
Am I missing something with gtest_discover_tests?
After having started the bounty, I re-started the research on my own. I found out, the simplest method out there is to have googletest installed system-wide.
So, first install the package. On Ubuntu 18.04, that was supt apt install googletest.
For some reason, I had to build the library (perhaps not necessary somehow though?):
cd /usr/src/googletest
mkdir bin && cd bin
cmake ..
make && make install
After that I have been able to compile and run a test case. My CMakeLists.txt testing section looks like this:
enable_testing()
find_package(GTest REQUIRED)
include(GoogleTest)
add_executable(tests tests/foo_test.cpp tests/bar_test.cpp)
target_link_libraries(tests GTest::GTest GTest::Main)
gtest_discover_tests(tests)
A minimal test case file looks like this in my project:
// tests/foo_test.cpp
#include "gtest/gtest.h"
TEST(Foo, Sum)
{
EXPECT_EQ(2, 1 + 1);
}
Compiling is as easy as:
mkdir bin && cd bin
cmake ..
./tests

CMake putting build files in source directory

I am very new to CMake. A friend wrote a simple CMakeLists.txt for the project I am coding myself. I am using svn and have just checked out an old version on the same machine into a different folder. Now, in the original source directory (where CMakeLists.txt is located) I create the directory 'build', cd into there, and for the time being run the code
cmake -DCMAKE_BUILD_TYPE=Debug ..
This nicely puts all of the files in the build directory
-- Build files have been written to: ~/MixedFEMultigrid/build
Now when I check out to another directory, create another 'build' directory in that one and then run the CMake command I get the following
-- Build files have been written to: ~/oldCode
where oldCode is actually the parent directory. I have no idea why this is happening. Can someone explain this to me? The full CMakeLists.txt file is given below,
cmake_minimum_required (VERSION 2.6)
project (MixedFEMultigrid)
FIND_PACKAGE(LAPACK REQUIRED)
set( SRC_FILES multigrid.c
gridHandling.c
interpolation.c
linApprox.c
params.c
sparseMatrix.c
testing.c
richardsFunctions.c
definitions.c
newtonIteration.c
)
#Adds the executable with all the dependencies
add_executable (multigrid ${SRC_FILES})
#Specifies the libraries to link to the target
TARGET_LINK_LIBRARIES(multigrid ${LAPACK_LIBRARIES} m)
# Update if necessary
set(CMAKE_C_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wno-long-long -pedantic -fstrict-aliasing -std=c99 -O3")
As per the comment by escrafford I am updating to show what I do on the command line.
cd ~
mkdir oldCode
cd oldCode
svn co <repository>
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
The build files are then put into the directory 'oldCode' instead of the 'build' directory. The following, on the other hand, puts the build files into the 'build' directory
cd ~
mkdir MixedFEMultigrid
cd MixedFEMultigrid
svn co <repository>
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
That comes from a in-source cmake execution
Remember to remove cmake cache:
$ rm CMakeCache.txt
$ mkdir debug
$ cd debug
$ cmake -DCMAKE_BUILD_TYPE=Debug ..
That has another benefit, given that cmake do not provide a clean target
$ cd ..
$ rm -rf debug
is the equivalent of make clean or more precisely make distclean