I started a project on linux and now want to build it on Windows 10. Therefore I use CLion as my IDE. CLion unfortunately could not resolve standard header symbols. Please see screenshots of my setup.
My Toolchain:
My CMake Setup:
My project tree:
Examples of the issue:
My CMakeLists.txt
cmake_minimum_required(VERSION 3.1)
project(vilsoc)
include_directories(include)
file(GLOB SOURCES "src/*.cpp")
set(LIBS sfml-graphics sfml-window sfml-system)
if (WIN32)
set(SFML_DIR "C:\\Program Files (x86)\\Libraries\\sfml-2.5.1-vs15-32bit")
find_package(SFML 2.5 COMPONENTS graphics audio REQUIRED)
if(NOT TARGET spdlog)
# Stand-alone build
set(SPDLOG_DIR "C:\\Program Files (x86)\\spdlog-1.3.1")
find_package(SPDLOG REQUIRED)
endif()
endif (WIN32)
add_executable(vilsoc main.cpp ${SOURCES})
if (WIN32)
target_link_libraries(vilsoc ${LIBS} spdlog::spdlog)
endif (WIN32)
if (UNIX)
target_link_libraries(vilsoc ${LIBS})
endif (UNIX)
file(MAKE_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/logs")
I want to point out that spdlog::info is a 3rd part DLL I use. If somebody can also give me a hint how to get this one resolved I would be thankful, too. But first I would love to have the standart headers being resolved.
Thanks.
On Mac/clang, CLion 2019.2 parses your project correctly; it rightfully doesn't find spdlog and sf namespaces, as they are not included.
The "standard headers on Windows" issue may be rooted in mingw64, it's not actively supported. The mentioned hack may or may not help. If switching to Visual Studio compiler is an option, try it.
If you are desperate, set the explicit path to standard library with include_directories(SYSTEM <dir1>).
Related
I'm trying to use the CMake functions protobuf_generate in one of my projects. However, I'd like to the build as lightweight as possible. If at all possible I'd like to do this without having to compile protobuf's source code, or install some package on my (windows) machine.
Is there a way to just download binaries and headers and tell CMake: "Here is everything you need", so I can swap new proto versions whenever I feel like?
# CMakeList.txt : Top-level CMake project file, do global configuration
# and include sub-projects here.
#
cmake_minimum_required (VERSION 3.5)
project ("CMakeProject1")
set(TARGET_NAME CMakeProject1)
SET(PROTOBUF_INCLUDE_DIR "/path/to/include")
SET(PROTOBUF_LIBRARY "/path/to/libprotobuf.lib")
SET(PROTOBUF_PROTOC_EXECUTABLE "/path/to/protoc.exe")
find_package(Protobuf)
protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS path/to/some_object.proto)
add_library(${TARGET_NAME} STATIC ${PROTO_SRCS} ${PROTO_HDRS})
I've wanted to use Clion for awhile but I've always had trouble with Cmake. Armed with Cygwin, I've almost gotten this stupid thing to work.
The issue is while I can compile a cmake file from within a cygwin terminal, in Clion I am told it cannot find the library I want.
Error:A required package was not found
The cmakelist.txt file
cmake_minimum_required(VERSION 3.3)
project(Test)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set(PKG_CONFIG_PATH /usr/lib/pkgconfig)
set(PKG_CONFIG_EXECUTABLE /usr/bin/pkg-config.exe)
set(SOURCE_FILES main.cpp)
add_executable(Test ${SOURCE_FILES})
INCLUDE(FindPkgConfig)
pkg_check_modules(SDL2 REQUIRED "sdl2")
MESSAGE(STATUS "SDL library: " ${SDL2_LDFLAGS})
TARGET_LINK_LIBRARIES(Test ${SDL2_LDFLAGS})
I have no idea if setting the variables PKG_CONFIG_PATH and others work, but they successfully build a makefile for my use in cygwin that builds correctly.
I've deleted the cache, remade the project and everything. It just refuses to work in Clion
If I understood correctly, your cmake config is unable to find SDL library. I found it better to use find_package command instead of pkg_check_modules.
In order to find_package(SDL2) to work, there must be FindSDL2.cmake module in directory, specified by CMAKE_MODULE_PATH variable (usually, it is cmake/Modules directory inside your source tree).
FindSDL2.cmake is not a part of CMake, but you can find one online easily (check my own modules, for example: https://github.com/dragn/cmake-modules).
Refer to this doc for details: https://cmake.org/Wiki/CMake:How_To_Find_Libraries.
Put FindSDL2.cmake to cmake/Modules directory and add this to your CMakeLists.txt:
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_SOURCE_DIR}/cmake/Modules)
find_package(SDL2 REQUIRED)
include_directories(${SDL2_INCLUDE_DIR})
...
target_link_libraries(${PROJECT_NAME} ${SDL2_LIBRARY})
NOTE: Sadly, it appears that Leonardo has not succeeded in finding volunteers for maintaining FindSDL2.cmake in SDL community: https://cmake.org/Bug/view.php?id=14826.
I am trying to link the psapi library to a project with cmake, nothing complex. Here's my cmake-file:
cmake_minimum_required(VERSION 2.8)
project(BenchmarkTests)
add_definitions(-DPSAPI_VERSION=1)
if (WIN32)
FILE(GLOB win32_head
Timer.h
win_Memory.h
win_Processor.h
BenchmarkTests.h)
FILE(GLOB win32_source *.cpp)
SET(win32_test ${win32_head} ${win32_source})
SET(LIBDIR_NAME "C:/Program Files (x86)/Windows Kits/8.1/Lib/winv6.3/um/x64/")
SET(LIBDIR $ENV{${LIBDIR_NAME}})
SET(LIBNAME "Psapi.Lib")
find_library (Psapi ${LIBNAME} {LIBDIR})
ADD_EXECUTABLE(bmTests ${win32_test})
TARGET_LINK_LIBRARIES(bmTests Psapi)
SOURCE_GROUP("win32" FILES ${win32_test})
endif()
There are no other "Psapi.Lib" files on my computer except for in ".../um/x86", but my system is 64-bit so I want the x64, no? Anyhow the output in CMake GUI for Psapi field is "Psapi-NOTFOUND" and in VS2013 all of the functions in Psapi.h recieve syntax errors. I guess since they can't link to the library. Am I forgetting something vital in my cmake file? Any suggested fix or alternative method is welcome, thanks in advance.
I get the same result when I try the below instead of find_library(...)
add_library(Psapi STATIC IMPORTED)
set_property(TARGET Psapi PROPERTY IMPORTED_LOCATION "C:/Program Files (x86)/Windows Kits/8.1/Lib/winv6.3/um/x64/Psapi.Lib")
For future reference I got it to work in CMake as follows, credit goes to Chibueze Opata on this question:
find_library (PSAPI Psapi)
...
add_executable(...)
...
target_link_libraries(Basic -lpsapi)
I'm a new guy to c++ and cmake here. I decided to test out cLion and cMake. I'm trying to write a simple email client for the command line. Other sources told me that the best way to implement a POP3 and SMTP functions would be to use POCO. Unfortunately, cMake is giving me trouble. The version that came with CLion is 3.2 but the version that my machine is running is 2.8.
~$ cmake --version
cmake version 2.8.12.2
First problem. I thought that I could bypass this by just installing POCO and doing the same thing that I used for openssl which I also had to download.
cMakeList.txt:
cmake_minimum_required(VERSION 3.0)
project(Email_Reader)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
#included paths for openssl and POCO.
INCLUDE_DIRECTORIES("/usr/include/openssl")
INCLUDE_DIRECTORIES("/usr/local/include/Poco/Net")
set(SOURCE_FILES main.cpp)
add_executable(Email_Reader ${SOURCE_FILES})
The documentation for POCO tells me that I need at least 3.0 to work but I feel I have 2 different cMakes on my machine. Can you help me, please?
You can get the latest CMake release from: http://www.cmake.org/download/
For Linux, it's this archive: http://www.cmake.org/files/v3.2/cmake-3.2.2.tar.gz
An easy way to use it is to put the extracted files in /opt/cmake/cmake-3.2 then create the following aliases (e.g. in ~/.bash_aliases:
alias ccmake3='/opt/cmake/cmake-3.2/bin/ccmake'
alias cmake3='/opt/cmake/cmake-3.2/bin/cmake'
alias cmake3-gui='/opt/cmake/cmake-3.2/bin/cmake-gui'
alias cpack3='/opt/cmake/cmake-3.2/bin/cpack'
alias ctest3='/opt/cmake/cmake-3.2/bin/ctest'
Then, make sure that you have properly built and installed POCO.
The Getting Started page has all the information you need for doing that. But, basically, you should get the sources from here and extract them somehwere:
wget http://pocoproject.org/releases/poco-1.6.0/poco-1.6.0.tar.gz
tar xvfz poco-1.6.0.tar.gz
cd poco-1.6.0
mkdir -p cmake_build cmake_install/debug cmake_install/release
cd cmake_build
cmake3-gui ..
In the CMake 3 GUI, press Configure. In the new window, keep the default option Unix Makefiles and click on Finish. An error message should appear (which is fine), click Ok.
To build the Debug version, set the following:
CMAKE_BUILD_TYPE : Debug
CMAKE_INSTALL_PREFIX : the absolute path to "cmake_install/debug"
To get you started quickly with POCO, unckeck all the options, except for the following, they have to be enabled:
ENABLE_JSON
ENABLE_NET
ENABLE_UTIL
ENABLE_XML
POCO_STATIC
(You can consider the other options later if you need to...)
Quit the GUI, then build/install POCO:
make clean
make -j8
make install
Now, POCO should be installed in cmake_install/debug. To build/install the other versions, just do the same procedure, but replace Debug in CMAKE_BUILD_TYPE with Release, RelWithDebInfo or MinSizeRel (cf. CMake's doc) (also, you'll have to change the install directories)
Finally, you can use POCO in you C++ projects.
For instance, your CMakeLists.txt should look like this:
cmake_minimum_required(VERSION 3.0)
project(Email_Reader)
# define the project
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set(SOURCE_FILES main.cpp)
add_executable(Email_Reader ${SOURCE_FILES})
# set the POCO paths and libs
set(POCO_PREFIX "/path/to/cmake_install/debug") # the directory containing "include" and "lib"
set(POCO_INCLUDE_DIR "${POCO_PREFIX}/include")
set(POCO_LIB_DIR "${POCO_PREFIX}/lib")
set(POCO_LIBS "${POCO_LIB_DIR}/libPocoNetd.a"
"${POCO_LIB_DIR}/libPocoUtild.a"
"${POCO_LIB_DIR}/libPocoJSONd.a"
"${POCO_LIB_DIR}/libPocoXMLd.a"
"${POCO_LIB_DIR}/libPocoFoundationd.a"
"pthread")
# set the include path for the app
target_include_directories(Email_Reader PRIVATE "${POCO_INCLUDE_DIR}")
# link the app against POCO
target_link_libraries(Email_Reader "${POCO_LIBS}")
My CMakeLists.txt for using Poco looks like this:
cmake_minimum_required(VERSION 3.10.0)
project(MyProject VERSION 0.1.0)
find_package(Poco REQUIRED COMPONENTS Foundation Net Zip )
add_executable(my_exe main.cpp)
target_link_libraries(my_exe PUBLIC Poco::Foundation Poco::Zip Poco::Net)
This configuration automatically add the needed include directories and libraries.
The Foundation component is mandatory, it seems it provides the include directories.
Don't add Poco to target_link_libraries, the linker will then look for a 'Poco' library.
I'm trying to make a project that has both ZLIB and LIBPNG (and other libraries). LibPNG's CMakeLists.txt file has this in it: find_package(ZLIB REQUIRED) It's stock code that comes with it and I don't want to change it.
I'm building on Windows (Visual Studio). This is a cross-platform application (Windows, Mac, Linux and Mobile devices) I cannot rely on /usr/lib versions of any libraries. So I'm building them all with my project together.
I can't get LibPNG to build unless I hack this up. In an upper-level CMakeLists.txt file, I put this in there:
ADD_SUBDIRECTORY(contrib/${CUSTOM_ZLIB_LOCATION})
SET(ZLIB_FOUND ON CACHE BOOL "Yes")
SET(ZLIB_INCLUDE_DIR ${CMAKE_BINARY_DIR}/contrib/${CUSTOM_ZLIB_LOCATION} {CMAKE_SOURCE_DIR}/contrib/${CUSTOM_ZLIB_LOCATION})
SET(ZLIB_LIBRARY zlib CACHE STRING "zlib library name")
This satisfies find_package(ZLIB REQUIRED) But I think this is a hack. Is there some straight forward way to build the local copy of zlib without all the 3 extra lines?
I only added this line at the beginning (at least before find_package(ZLIB REQUIRED)) and it worked for me.
set(ZLIB_ROOT <zlib folder here>)
But others may need doing something like:
if (CMAKE_VERSION VERSION_GREATER 3.12 OR CMAKE_VERSION VERSION_EQUAL 3.12)
# Enable find_package uses of <PackageName>_ROOT variables.
cmake_policy(SET CMP0074 NEW)
endif()
set(ZLIB_ROOT <zlib folder here>)
We set the policy to NEW.
The OLD behavior for this policy is to ignore <PackageName>_ROOT variables.
CMake version 3.22.1 warns when the policy is not set (and defaults to OLD behavior).