I'm using CLion to work on a CMake project, and I would like to specify paths in the project's "CMake options" with CLion's path variables. However, when I replace a basedir with CLion's $PROJECT_DIR, the path isn't expanded.
Does anyone know if it's possible to use CLion's path variables in CLion's "CMake options" so that the variables are expanded when cmake is being configured?
Related
This may be related to my previous question.
I copied the code from the "Simple Example" here.
I copied the cmake instructions from here.
The error I am getting is:
-- Checking for module 'gtkmm-3.0'
-- No package 'gtkmm-3.0' found
CMake Warning (dev) in CMakeLists.txt:
No cmake_minimum_required command is present. A line of code such as
cmake_minimum_required(VERSION 3.10)
should be added at the top of the file. The version specified may be lower
if you wish to support older CMake versions for this project. For more
information run "cmake --help-policy CMP0000".
This warning is for project developers. Use -Wno-dev to suppress it.
-- Configuring done
-- Generating done
-- Build files have been written to: /path-to-files/
This is my CMakeLists.txt
project(SimpleExample)
find_package(PkgConfig REQUIRED)
set(CMAKE_PREFIX_PATH "/usr/lib/x86_64-linux-gnu/pkgconfig;/usr/share/pkgconfig")
pkg_check_modules(GTKMM gtkmm-3.0)
link_directories(${GTKMM_LIBRARY_DIRS})
include_directories(${GTKMM_INCLUDE_DIRS})
add_executable(SimpleExample SimpleExample.cpp)
target_link_libraries(SimpleExample ${GTKMM_LIBRARIES})
There's a really dumb line in here set(CMAKE_PREFIX_PATH "/usr/lib/x86_64-linux-gnu/pkgconfig;/usr/share/pkgconfig") which I'm fairly sure isn't supposed to be there, however in my previous question I was struggeling to figure out why pkg-config wasn't finding the correct locations for the gtkmm-3.0.pc file.
So I did a search to try and figure out how to set the paths for pkg-config manually in a CMake file. That is what I came up with. However it does not work.
CMake variable CMAKE_PREFIX_PATH and environment variable PKG_CONFIG_PATH denote different paths:
CMAKE_PREFIX_PATH points to the installation prefix(es) of the one or more programs.
PKG_CONFIG_PATH points to location(s) of .pc files.
When CMake wants to call pkg-config via pkg_check_modules command, it translates content of CMAKE_PREFIX_PATH variable into PKG_CONFIG_PATH by appending sufficies to every path in CMAKE_PREFIX_PATH variable (see branch if(NOT "${_extra_paths}" STREQUAL "") in FindPkgConfig.cmake):
lib/pkgconfig
share/pkgconfig
lib32/pkgconfig or lib32/pkgconfig for some distros
some other system-specific sufficies
As you can see, you may obtain /usr/share/pkgconfig in PKG_CONFIG_PATH by using /usr in CMAKE_PREFIX_PATH.
But obtaining /usr/lib/x86_64-linux-gnu/pkgconfig in PKG_CONFIG_PATH is very questionable.
In any case, parameters described the host system itself are normally passed via environment or cmake arguments, not by the project's CMakeLists.txt. In given case command line
export PKG_CONFIG_PATH="/usr/lib/x86_64-linux-gnu/pkgconfig:/usr/share/pkgconfig"
is much more simpler (and reliable) than setting CMAKE_PREFIX_PATH CMake variable.
I'm trying to test a project on a cluster where I can't install some libraries in the default locations, so I'm trying to override the default CMake search path with the CMAKE_INCLUDE_PATH environment variable.
Unfortunately it doesn't seem to be picked up. I'm having to set the path explicitly with
include_directories("." $ENV{CMAKE_INCLUDE_PATH})
but this seems like a bit of a hack. So I have two questions:
Is this expected behavior?
Is there some cleaner way to add a directory to CMake's include path via an environment variable?
First of all, there is a predefined cmake variable CMAKE_INCLUDE_PATH variable that is a ";-list of directories specifying a search path for the find_file() and find_path() commands." This is not meant to specify the compiler include path.
Secondly, good use of cmake should not involve environment variables. To the extent you can, you should use the conventional cmake find_package to configure your build paths. When you need to explicitly add a path to the compiler include search path, then, yes, include_directories is what you need. But you should a cmake cache variable rather than environment variable. For details on setting a cache variable, see this page, which says
set(<variable> <value>... CACHE <type> <docstring> [FORCE])
For your example this becomes:
set(MYINCLUDE /usr/local/foo/include CACHE PATH "path to the foo include directory")
include_directories(${MYINCLUDE})
Then if you need to override the default /usr/local/foo/include, you may specify it with the command line used when invoking cmake; e.g., cmake -DMYINCLUDE=/home/foo/include .
I'm trying to build libwebsockets inside of my project in CLion. During build libwebsockets creates a header file that is required by other files and puts it in PROJECT_BINARY_DIR. CLion builds everything inside a random build directory it creates for the project and the header file ends up in that directory. I've tried:
Setting the websockets_BINARY_DIR variable
Setting the CMAKE_RUNTIME_OUTPUT_DIRECTORY variable
Setting CMAKE_LIBRARY_OUTPUT_DIRECTORY variable
Changing every variable in the CMake cache to point away from CLion's random directory
Changing the build output path setting in CLion's preferences
None of these work, Which leads me to my questions:
Is there a way to tell CLion where to build (not just where to put some of its output buthow to override the random directory it chooses).
If there isn't a way to tell CLion where to build, is there another variable that I should be setting?
I don't know how to set build dir.
Examples of how to set up bin directory with Clion below
set(dir ${CMAKE_CURRENT_SOURCE_DIR})
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${dir}/bin")
or (separate for .exe, .dll, .lib):
set(dir ${CMAKE_CURRENT_SOURCE_DIR})
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${dir}/lib")
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${dir}/lib")
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${dir}/bin")
Also I added link about how to set up build directory:
https://stackoverflow.com/a/28200869/3001953
But it soesn't work in my case (Clion 1.1).
You may also have a look at the Clion built-in path variables: https://www.jetbrains.com/help/clion/2019.2/absolute-path-variables.html
I'm using the FindProtobuf module in a project where the protocol buffer files are in a sub-directory. I want the CMakeLists.txt file in that sub-directory to invoke protoc to generate the CPP Files. My project folder structure is like this:
cammy/CMakeLists.txt # Root CMakeLists.txt
cammy/protofiles/test.proto # protofile
cammy/protofiles/CMakeLists.txt
I have the include(FindProtobuf), the find_package invocation and the call to PROTOBUF_GENERATE_CPP in the CMakeLists.txt file in protobuf folder.
The executable build step is in the Root CMakeLists.txt file and I add the generated files
to the target executable in this file
ie.
add_executable( ${EXEC} ${SRCS} ${PROTO_SRC} ${PROTO_HEADER} )
target_link_libraries( ${EXEC} ${PROTOBUF_LIBRARIES} )
are both defined in the root CMakeLists.txt
When I run cmake, it does not run protoc to generate the Source files even though I expilicitly tie generated sources to the executable thereby creating a dependency.
When I move all the contents of CMakeLists.txt in the protofiles folder into the root CMakeLists.txt, the proto files are compiled.
Can anyone help me with this? I want all the protocol buffer building stuff to go in the CMakeLists.txt file created in the protofiles folder.
I also noticed that variables generated in the inner CMakeLists.txt ( like PROTO_SRC ) are defined in the inner file when printed ( ie I get the correct generated CPP filename ) but when I print the same variable in the root file.. it is empty. Its almost as though I need to "export" (if there were a way in cmake ) the variables out to the root folder.
Any help would be much appreciated.
Thanks
Kartik
I think [FindProtobuf][0] isn't really meant to be used this way. From its docs:
NOTE: The PROTOBUF_GENERATE_CPP macro & add_executable() or add_library()
calls only work properly within the same directory.
You're trying to use the PROTOBUF_GENERATE_CPP macro in a subdirectory, and although the CMake docs don't really make it clear, a subdirectory introduces a new scope for variables. This means that any variables set or modified in the subdir scope don't affect similarly-named variables in the parent scope. Hence the reason for PROTO_SRC being available in your protofiles dir, but not in the parent.
The way to pass variables up a scope is to use [set(... PARENT_SCOPE)][1], so in protofiles/CMakeLists.txt you could do:
PROTOBUF_GENERATE_CPP(PROTO_SRC PROTO_HEADER test.proto)
set(PROTOBUF_INCLUDE_DIRS ${PROTOBUF_INCLUDE_DIRS} PARENT_SCOPE)
set(PROTOBUF_LIBRARIES ${PROTOBUF_LIBRARIES} PARENT_SCOPE)
set(PROTO_SRC ${PROTO_SRC} PARENT_SCOPE)
set(PROTO_HEADER ${PROTO_HEADER} PARENT_SCOPE)
However, this still doesn't get us all the way!
CMake doesn't actually invoke the protoc compiler to generate the .pb.h and .pb.cc files - it uses [add_custom_command][2] to do this. The custom command specifies the .pb.h and .pb.cc files as outputs, and the custom command is only invoked (i.e. protoc executed) if a subsequent target which depends on these files is built.
So, at configure time (when CMake executes) these files don't exist. This is a problem if you try to add them as sources to an add_library or add_executable command - CMake needs to be told that these files don't exist when it runs, but that they will exist at build time.
The way to do that is to set the [GENERATED][3] property to TRUE for these files. The PROTOBUF_GENERATE_CPP macro does that automatically, but as with the variables, the property isn't populated up into the parent scope. So in your top-level CMakeLists.txt, you also need to add:
set_source_files_properties(${PROTO_SRC} ${PROTO_HEADER} PROPERTIES
GENERATED TRUE)
As you can see, using PROTOBUF_GENERATE_CPP in a different dir to the corresponding add_library/add_executable commands is a bit fragile. If you can avoid doing it, you probably should.
[0]: https://cmake.org/cmake/help/latest/module/FindProtobuf.html "CMake latest documentation for "FindProtobuf" module"
[1]: https://cmake.org/cmake/help/latest/command/set.html "CMake latest documentation for "set" command"
[2]: https://cmake.org/cmake/help/latest/command/add_custom_command.html "CMake latest documentation for "add_custom_command""
[3]: https://cmake.org/cmake/help/latest/prop_sf/GENERATED.html "CMake latest documentation for "GENERATED" source file property"
I have a CMake project where I am using a library and now I want to test my code with a different version of that library. I can set INCLUDE_DIRECTORIES (and possibly later also linking) in the below example. But because I only want to do this temporarily, I'd like to manually set this path with ccmake/cmake-gui.
How do I do this?
project(min_example)
cmake_minimum_required(VERSION 2.8)
find_package(OpenCV REQUIRED)
# Without the following line please:
INCLUDE_DIRECTORIES("/home/me/src/opencv/install/include")
add_executable(min_example main.cpp)
target_link_libraries(min_example ${OpenCV_LIBS})
This should be possible by setting the CMAKE_PREFIX_PATH variable upon configuring your build. In your project directory generate a test_build directory and run:
mkdir test_build
cd test_build
cmake -DCMAKE_PREFIX_PATH=/home/me/src/opencv/install ..
Setting the CMAKE_PREFIX_PATH variable will make the find_package(OpenCV REQUIRED) command pick your OpenCV installation in /home/me/src/opencv and set the OpenCV_LIBS and OpenCV_INCLUDE_DIR variables accordingly.
Alternatively you can edit a CMakeCache.txt file of an existing build directory with the CMake GUI editor and add the CMAKE_PREFIX_PATH definition there. You have to re-configure your project then.
Using config in find_package will restrict search path to OpenCV_DIR. This will use the cmake config that opencv generates at build time to setup paths to include and libs
set(OpenCV_DIR "<cusompath>" CACHE PATH '' ${SHOULD_FORCE_CACHE})
find_package(OpenCV REQUIRED CONFIG)