After creating a new package and code in it, I got the one below;
[rosrun] Couldn't find executable named tf_result below
/home/aybakana/catkin_ws/src/pcl_tutorials
I tried all sourcing stuff etc. but it does not work.
Does anyone know why it happens?
I figured it out that the reason is that I deleted the part below from CMakeLists.txt file.
catkin_package( ## if you dont add this, executables are not found
INCLUDE_DIRS include
LIBRARIES pcl_tutorials
CATKIN_DEPENDS geometry_msgs nav_msgs pcl_msgs roscpp rospy std_msgs
DEPENDS system_lib
)
For me, this occurred when I made invalid changes to my CMakeLists.txt. Ensure that the app can compile then try running catkin_make again.
If not, then try removing your devel and build folders and rebuild your application. Don't forget to source your setup.bash file: source ./devel/setup.bash before running your node again.
Related
My CMakeLists.txt file contains commands, which should be executed by make install, and all this works fine. The sample CMakeLists.txt below is a short excerpt from my actual CMake file (the tm0001.cpp content is not important here - it might be any C++ program):
cmake_minimum_required(VERSION 3.12)
project(tm0001)
set(CMAKE_CXX_STANDARD 11)
add_executable(${PROJECT_NAME} tm0001.cpp)
install(
TARGETS ${PROJECT_NAME}
DESTINATION /usr/local/bin
PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE
)
install(CODE "message(\"-- This must be called during installation only\")")
set(CPACK_PACKAGE_CONTACT "HEKTO")
set(CPACK_GENERATOR "DEB")
include(CPack)
I see the message command is executed by make package as well, which is not I want.
How to tell CMake not to execute installation scripts by the make package command? I couldn't find any way to do that with the CMake if command.
As it already said in the comment, it's an extremely bad idea to "work w/ systemd" (and doing anything not related to build or packaging of your project) from install commands. The install command (even SCRIPT and CODE signatures) are intended to be used for install actions and not for any other side effects.
The correct way to act here is to produce a native package (DEB/RPM) w/ post-install script, where using the system-provided macros (like described here), you can install your package properly. Take a look to CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA for the way to provide package install actions.
The other bad thing is to use the hardcoded path (/usr/bin/). And BTW, a better place for the (pure) daemon app I suggest /usr/sbin/. Take a look to GNUInstallDirs module shipped w/ CMake for further references.
What I did was to specify install commands with CODE/SCRIPT as separate component e.g. install(CODE ... COMPONENT post-install).
Then also added other non-code install commands as a different component e.g. install(FILES ... COMPONENT files-install)
The CPack then needs to be configured to package only files-install component (solution to this can be found easily - hint: use CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE, CPACK_COMPONENTS_ALL and CPACK_(RPM/DEB/...)_COMPONENT_INSTALL variables).
Of course then the resulting package won't run these CODE components during installing the package - they need to be added separately as a post install script.
I'm answering my own question, because the existing answer doesn't address my main problem. I couldn't find any way (on the CMake level) to block install commands from running during make package - even the postinst script is called by this command.
Fortunately, I could modify the postinst script itself to do nothing in case it's called not by the dpkg:
if [ -z ${DPKG_ADMINDIR} ]; then
echo "postinst: missing 'dpkg' environment (not an error during packaging)"
exit 0
fi
It's a trick of course, but it worked for me.
I used cmake 3.12.0. There are exists one cmake project that creates one console application. I add the ability of package generation to that cmake project:
# ... above cmake code for one console application creation
# below code that I add:
# pack
set (A_PACK_DESCRIPTION_SUMMARY "${PROJECT_NAME} - CMake Assistant Solution")
set (A_INSTALL_PREFIX Consolas)
set(CPACK_WIX_PRODUCT_GUID "F9AAAAE2-D6AF-4EA4-BF46-B3E265400CC8")
set(CPACK_WIX_UPGRADE_GUID "F9AAAAE2-D6AF-4EA4-BF46-B3E265400CC7")
set(CPACK_GENERATOR "WIX")
include(CPack)
With other generators (NSIS, 7Z, ZIP, DEB) all works fine but with WIX appears followed error:
...path\files.wxs(11) : error LGHT0091 : Duplicate symbol 'Component:CM_C_EMPTY_INSTALL_ROOT' found. This typically means that an Id is duplicated. Check to make sure all your identifiers of a given type (File, Component, Feature) are unique.
Why it happens and how to fix it?
This appears to be caused by this bug
Basically you use add_subdirectory(xxx EXCLUDE_FROM_ALL) where the subdirectory has a install(... COMPONENT ...) call. The installed files are excluded from the subdirectory, but still creates COMPONENTs, which are now empty and break wix.
As a workaround, you can add:
set(CPACK_COMPONENTS_ALL Unspecified)
in CMakeLists.txt to exclude all the empty components.
If it helps any, I had this problem and found that I had INSTALL commands that specified only Release Configurations but then tried to build the package using the Debug build configuration. By just switching to building the package specifying the Release configuration all went as expected (Wasted most of an afternoon before I figured this out!)
I understand that by default, Clion creates the binary files for a project loaded in Clion in all the four configurations:
(Debug;Release;MinSizeRel;RelWithDebInfo)
as well as one called: __default__.
I am using a third party cmake module which downloads an external project in a way that add_subdirectory() can be run on it so it would be included in the root project.
add_subdirectory(${downloaded_proj_src_dir} ${downloaded_proj_bin_dir} EXCLUDE_FROM_ALL)
In this setup, if I decide to place the child project outside the binary directory of the root project, I get:
Error:Binary directories outside of CMake build directory are not supported. Most likely this error is caused by an add_subdirectory command with an explicitly specified binary_dir argument.
which is an understandable restriction by CMake.
now if I instead decide to set the binary directory of the downloaded project in a subdirectory of the binary directory of the parent project, ie:
set(downloaded_proj_bin_dir "${CMAKE_BINARY_DIR}/${downloaded_proj}-build")
...
add_subdirectory(${downloaded_proj_src_dir} ${downloaded_proj_bin_dir} EXCLUDE_FROM_ALL)
I will get the file created in the parent binary directory of all the build configurations because ${CMAKE_BINARY_DIR} is different for each configuration. To avoid seeing all these directories listed on the project view sidebar, I have set the CMAKE_CONFIGURATION_TYPES to be Debug. But even then, I get:
Error:Configuration Debug
The current CMakeCache.txt directory /path/Debug/downloaded_proj_bin/CMakeCache.txt is different than the directory /path/__default__/downloaded_proj_bin/CMakeCache.txt where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt
Clearly something is going on with this __default__ configuration which I don't understand. So the question is, what is the significance of this default configuration and why should there be a conflict here?
P.s. Setting the configuration to __default__ does not solve the problem as I will have a __default__0 configuration created instead and get the same error.
Update: some further observations
My enviornment variables set in IDE don't have any effect on the cmake builds.
Cmake "options" however which presumably will be passed as arguments to cmake do seem to work.
-D CMAKE_CONFIGURATION_TYPES=Debug.
When I specify the command line option, I get
Warning:Manually-specified variables were not used by the project:
CMAKE_CONFIGURATION_TYPES
But it clearly does have the effect of no longer creating the other build configurations. My guess is that this message relates to the __default__ build which is ignoring the argument.
Even in the case of specifying CMAKE_CONFIGURATION_TYPES in the IDE, I still get the additional __default__ build which is apparently unaffected by the CMAKE_CONFIGURATION_TYPES assignment.
Logging: message("Build type: ${CMAKE_BUILD_TYPE} ) does not return any build_type.
Outputting message(and generator: ${CMAKE_GENERATOR} ") returns "Unix-make files" for both, so both are being generated with the same generator.
Taking a diff from the CMakeCache.txt files, I can see that they are identical.
Do you have in DownloadProject.cmake the right setting? for:
set(_DownloadProjectDir "${CMAKE_CURRENT_LIST_DIR}")
I had the same problem trying to set google test(with the help of https://github.com/Crascit/DownloadProject) and my _DownloadProjectDir was setted as "test". Maybe when I moved this cmake file in my project Clion changed that automatically.
So, it turns out that you can sort this out quite easily by adding the following line above line 145 in DownloadProject.cmake:
file(REMOVE "${DL_ARGS_DOWNLOAD_DIR}/CMakeCache.txt")
This seems to be because CLion copies the default across to the other configurations and doesn't clear the cache. This is a problem only because DownloadProject creates a project within the project (I think...). Anyway, deleting this file before configuring the CMakeLists.txt by-passes this issue. I'll submit a pull request to the DownloadProject repository as this doesn't seem to have any adverse effects when not using CLion.
I have found in library Poco under contrib a PocoConfig.cmake which I've copied under /cmake/Modules
I also added in my CMakeLists.txt:
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/Modules/")
Now I run under /Build/cmake ..
And I keep getting:
CMake Error at CMakeLists.txt:41 (find_package):
By not providing "FindPoco.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Poco", but
CMake did not find one.
Could not find a package configuration file provided by "Poco" with any of
the following names:
PocoConfig.cmake
poco-config.cmake
Add the installation prefix of "Poco" to CMAKE_PREFIX_PATH or set
"Poco_DIR" to a directory containing one of the above files. If "Poco"
provides a separate development package or SDK, be sure it has been
installed.
Obviously CMake is not finding the module file. What am I doing wrong, how to explicitly point CMake to that module file?
The PocoConfig.cmake doesn't works with find_package (otherwise, it would be named FindPoco.cmake), that's why you're getting this error.
Just include the PocoConfig.cmake in your CMakeLists.txt with:
include(${CMAKE_SOURCE_DIR}/cmake/Modules/PocoConfig.cmake)
I've had similar issues. In my case I was recompiling with an old build folder in place - deleting the folder and recompiling worked.
I installed Ogre3D 1.8.1 (the source package) on Ubuntu 12.04 and everything went fine (I managed to run some samples on the Ogre interface). However, I hit a problem while I was compiling an external project (that one) that needed the OpenCV, ArUco and Ogre librarys. When I run the CMake of the project, I receive the following:
CMake Error at CMakeLists.txt:46 (find_package):
By not providing "FindOGRE.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "OGRE", but
CMake did not find one.
Could not find a package configuration file provided by "OGRE" with any of
the following names:
OGREConfig.cmake
ogre-config.cmake
Add the installation prefix of "OGRE" to CMAKE_PREFIX_PATH or set
"OGRE_DIR" to a directory containing one of the above files. If "OGRE"
provides a separate development package or SDK, be sure it has been
installed.
-- Configuring incomplete, errors occurred!
I know where the FindOGRE.cmake is, it's in the /usr/local/lib/OGRE/cmake, but I don't know how to say to CMake to look for that folder and fix this problem.
You just need to use the -D command line option along with the CMAKE_MODULE_PATH variable:
cmake . -DCMAKE_MODULE_PATH=/usr/local/lib/OGRE/cmake
Just for the record, an alternative solution would be to add the module path directly in the CMakeLists.txt. For example (tested on Debian 9):
set(CMAKE_MODULE_PATH "/usr/share/OGRE/cmake/modules/;${CMAKE_MODULE_PATH}")
Just make sure to add the line before find_package is called.
For me, it only works to set the following in CMakeLists.txt before find_package:
set(OGRE_DIR /usr/share/OGRE/build/sdk/CMake)
Note that the CMake directory is the one containing OGREConfig.cmake. For some reason, my CMake ignores CMAKE_MODULE_PATH.
Maybe, of some help for someone
For me, this solution work on manjaro:
set(CMAKE_MODULE_PATH "/usr/lib/OGRE/cmake;${CMAKE_MODULE_PATH}")
find_package(OGRE QUIET)
if (OGRE_FOUND)
include_directories( ${ogre_INCLUDE_DIR})
link_directories(${OGRE_LIBRARIES})
message(STATUS "OGRE: FOUND")
else()
message(STATUS "OGRE: NOT FOUND")
endif()