This is my first time using cmake gui in windows. I am trying to install the vsomeip library in Windows. This is mainly required for my common API someip application. Now, I am having issue to compile the vsomeip library. When I run CMake gui, it says Could NOT find Boost (missing: system thread filesystem) (found suitable version "1.67.0", minimum required is "1.55")
I have already added the boost directory to my environment Path variable. I am not sure whether are there any additional configurations is required. When I try the same in Linux, it works fine. Only in Windows there is an issue.
I fixed the issue by changing the boost version inside the boost/version.hpp.
Previously the version was written as 1_55_0. So I just changed the version to 1_55.
The other fixed was to add the environment variable Path. I added the boost include directory itself: C:\local\boost_1_55_0\boost
I am not sure this is the right way for the fix but this fixes worked for me. Maybe if you guys have better solution can share it here.
When using CMake on unix I dont have any issues. I can use CLion to do a cmake setup, cmake build and cmake install, open a different project and it will find the previously built library when using find_package. On windows this does not seem to be possible. By default it tries to install the build code into strange directories (like C:\Program Files). I have added a CMAKE_INSTALL_PREFIX to both my library CMakeLists.txt and the appliation CMakeLists.txt, however when using find_package(SDL2)CMake still complains there is no config file for CMake and SDL2. When checking the following file exists:
U:\various\cmake-cache\Program Files (x86)\SDL2\cmake\SDL2Config.cmake
The directory U:\various\cmake-cache was used as CMAKE_INSTALL_PREFIX for both SDL2 and my application. Yet it still refuses to compile.
What can I do to make CMake at least somewhat useful on windows? On Unix things work great, but it feels like a huge PITA on Windows so far... It seems like all the concepts dont work there. I would really like to have one central location that is used by every CMake build on my system and everything is installed there and when another project uses a library it is searched there. Is this possible?
I'm trying to cross-compile a gRPC using cmake.
I actually managed to do it. Unfortunately my method involves tinkering inside CMakeLists.txt.
Problem was that, when I was trying to compile gRPC it was using protobuffer he just compiled. It cannot run ARM compiled executables on x86 machine.
I managed to compile it by specifying path to protoc and grpc_cpp_plugin manually in gRPCs main CMakeLists.txt. It is dirty and since I would like to include gRPC as submodule I need clean way to do it.
Has anyone managed to cross-compile gRPC using cmake?
This way should work:
Cross-compile Protobuf for target(ARM) and install it.
Make sure that cross-compiled Protobuf can be searched in the toolchain(ARM) you have.
E.g. it is installed into system-default prefix under sysroot.
On host, install Protobuf of the same version. It needn't to be searchable (that is, user-local installation is sufficient).
Cross-compile gRPC with following parameters (set in CMake GUI or as -D option for cmake executable):
gRPC_PROTOBUF_PROVIDER: package
gRPC_PROTOBUF_PACKAGE_TYPE: MODULE
Protobuf_PROTOC_EXECUTABLE: <path to your host protoc executable>
Explanations
Setting parameter gRPC_PROTOBUF_PROVIDER to "package" tells gRPC to not build its own Protobuf, but use already installed variant. This variant is searched by find_package(Protobuf).
Setting parameter gRPC_PROTOBUF_PACKAGE_TYPE to "MODULE" tells gRPC to not use "Config" file, provided by Protobuf installation, for detect Protobuf things (libraries and executable). Config file contains hardcoded paths which cannot be adjusted outside. Instead, FindProtobuf.cmake script is used for find Protobuf.
Setting parameter Protobuf_PROTOC_EXECUTABLE tells FindProtobuf.cmake script to not search Protobuf executable, but takes it from the parameter.
I'm trying to create an Open Source C++ project. I want it to be as easy to build as possible, but at the same time cross platform.
I don't need gui or heavy libraries like boost or Qt, so I've settled on using GitHub, CMake, and LibSourcey.
My problem is, I can't find a way to make my project easy to build in windows, which is my development environment.
How can I "make install" a library in Windows for use in my project? Do I even have to install it in windows?
Is it possible to download, build, and link it automatically?
On windows, besides an installer, I also want to make a portable version, so don't want any hard coded library paths.
I assume, on some platforms, like Linux, libraries are built separably and packaged up by maintainers. So I shouldn't just bundle up my own copies.
So, my question is:
How can I set up a project that is cross platform and easy to build, and what are the best practices?
You can create git submodule in your git repo with path for example
contrib/LibSourcery and url to github repo of LibSourcery, because of LibSourcery uses cmake you just
need add such line into your CMakeLists.txt: add_subdirectory(contrib/LibSourcery)
So person who want to use your code, just do git clone --recursive url
to get all of your code and dependencies, after that it run cmake -G, to create project for IDE of his choice (including MSVC++ of course),
open project in IDE and press build button, that's all.
Use babun. It's a wrapper for cygwin and it works perfectly for everything I need, even compiling with cmake.
Alternatively, you could use premake, which uses lua as a config system and works fine on windows.
There is no elegant cross-platform way, since the idea of "make install" doesn't exist on Windows, therefore the use of cmake install is undefined there. For something which is supposed to help cross-platform, I feel this is a deficiency w cmake.
My solution is to write a custom _INSTALL which takes the same args as cmake install and then on Linux it just calls install, and on Windows it does an add_command which does a post-build copy to the install paths, which accomplishes the same thing. Basically, _INSTALL behaves the way you expect a cross-platform install command to behave. Can share my _INSTALL func if there is interest.
_INSTALL is placed nto a Helper.cmake, and included in all my CMakeList.txt for my projects, so all I need to do is call it and the generated lib/inc files magically appear for both win and linux.
You can use vcpkg, an open source package manager for c and c++. It allows to easily download and compile libraries and then use find_package from within CMake like you would on linux. It's very easy to use. It even provides hints as to how to alter your cmake file to use the libraries.
I started by installing packages with the command line, and then wondered why they wouldn't show up in visual studio. But I realized that it would download 32 bit libraries by default. Use .\vcpkg install <libname>:x64-windows if you need the 64 bit libraries.
After running the integrate command, you will need to delete any cmake caches to have MSVS use the new toolchain.
I'm new to CMake and to Boost!
I'm on a mac, so I can't test Boost code on my machine. I have a VM with Ubuntu. I am using JetBrains CLion IDE, which uses CMake to build. I've been unsuccessful with every tutorial I have tried. So, I just decided to make a project that does nothing. I've added the Boost information to the CMakeLists.txt file:
EDIT
Since I really didn't understand the CMakeLists.txt configuration, I learned that I was using one wrong configuration and needed to just remove the set(Boost_LIBRARY_DIR /usr/local/arm/lib) command. Here is a new image of the CORRECT CMakeLists.txt file.
I can't find where Boost_LIBRARIES is getting configured, which might have something to do with my problem. You can see main does nothing but print out "Hello, World!"
Here is the error I get when I try to build:
Boost_LIBRARIES is configured when you call find_package(Boost 1.54 ....)
The line
set (Boost_LIBRARY_DIR /usr/local/arm/lib)
has no impact in your code.
The mac still uses the intel processor, AFAIK, and so would your Ubuntu VM. From the location of your boost libraries it looks like boost was compiled for arm. Do you have other boost libraries installed on your system? Did you install boost yourself?
a