Run CMake's PACKAGE target from Visual Studio 2017 - c++

I try to build a C++ project with CMake on Visual Studio 2017. So far the CMake support is quite convincing. However, how do I call the PACKAGE target introduced by cpack? Does anyone have an idea how to do this from within the GUI (it does not show up in the context menu of the CMakeLists.txt file). The INSTALL as well as the BUILD_ALL target show up in the context menu of the CMakeLists.txt file but the PACKAGE target is missing. Is this a bug or am I missing something?

The default CMake PACKAGE target is only added by CMake if a file named CPackConfig.cmake exists in the outermost CMake build directory.
The CPackConfig.cmake file is usually generated automatically by CMake when the CPack module is included. It may however be generated under a different name, if the variable CPACK_OUTPUT_CONFIG_FILE is set before the inclusion of CPack.

Related

Visual Studio's CMake with vcpkg: Error gdal is not found

I have been trying to build a cmake c++ project. More specifically I am trying to use the gdal library in this project. In the CMakeLists.txt it says find_library(GDAL gdal) after doing some research i found, that visual studio can open cmake files by default as mention in this thread: https://learn.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019.
Moreover, visual studio should also automatically include the gdal library once i have set it up with vcpkg correctly. I've already downloaded the x64-windows version of the library (vcpkg install gdal:x64-windows) in order to build for the right architecture and made it available via vcpkg integrate install on a user-wide scope.
After some trial and error, everything works fine now, the toolchain gets included accordingly and the library is found automatically, resulting in a configuration like that:
However, when trying to include the header files (or anything else; see code snippet), visual studio does not seem to link the library correctly as it will result in the error message: cannot open source file "gdal/gdal.h".
#include <gdal/ogrsf_frmts.h>
#include <gdal/gdal.h>
#include <gdal>
Where should I further investigate?
As others have said vcpkg integrate install and vcpkg.cmake don't work together the reason being:
set_target_properties(${name} PROPERTIES VS_USER_PROPS do_not_import_user.props)
set_target_properties(${name} PROPERTIES VS_GLOBAL_VcpkgEnabled false)
this deactivates the integration. The reason to deactivate the integration is so that you don't write an incomplete CMakeLists.txt (e.g. missing the include directory or not linking all required libraries).
As such replace find_library(GDAL gdal) with find_package(GDAL REQUIRED) and target_link_libraries against the target GDAL::GDAL (https://cmake.org/cmake/help/v3.17/module/FindGDAL.html)

Compile GLEW with CMake and Visual Studio 2019?

I tried to compile (build) GLEW source code with CMake and Visual Studio 2019 for get binaries. In directory (disk) C:\ I created folder GL and inside it, placed unzipped glew-2.1.0. In C:\GL\, I created the folder build. Because I found the file "CMakeLists.txt" in 3 folders,
C:\GL\glew-2.1.0\build\conan\test_package
C:\GL\glew-2.1.0\build\cmake
C:\GL\glew-2.1.0\build\cmake\testbuild
I tested all 3 paths in "Browse Source..." text box in CMake. In "Browse Build..." text box I pasted C:/GL/build.
In all 3 tests CMake responded:
"CMake Error: The source
"C:/GL/glew-2.1.0/build/cmake/CMakeLists.txt"
does not match the source
"C:/GL/glew-2.1.0/build/cmake/testbuild/CMakeLists.txt"
used to generate cache. Re-run cmake with a different source directory."
that is "file CMakeLists.txt in 2nd path does not match file of same name in 3rd path".
If you change the top-level source directory on which CMake runs, you should first delete your CMake cache (File > Delete Cache in CMake GUI), and run CMake from scratch to avoid these errors.
Have you tried the CMake instructions on the GLEW Github here? Try running these commands from the command line:
> cd C:/GL/glew-2.1.0/build
> cmake ./cmake
Though this deviates from the typical out-of-source build CMake idiom, this is how GLEW intends the build system be created. So on your system:
Source directory: C:/GL/glew-2.1.0/build/cmake
Build directory: C:/GL/glew-2.1.0/build
Note, the GLEW build instructions warn about the use of CMake for building this repo:
The cmake build is mostly contributer maintained. Due to the multitude of use cases this is maintained on a best effort basis. Pull requests are welcome.
Thus, you may have better luck following the typical Windows build approaches recommended here.
According to Mr. squareskittles answer-comment to my comment to his answer, that I have tested successfully, correct answer is that the folder to accommodate binaries should be C:/GL/glew-2.1.0/build or any folder you have created in glew-2.1.0. It is peculiarity of glew though. With GLFW you can create accommodating binaries folder outside it. However according to Mr.squareskittles's edit in his answer which I have tested successfully, if you delete Cashe (in CMake GUI, click File > Delete Cashe) you can create accommodating binaries folder outside glew-2.1.0. Regards.

CMake Error at C:\Users\...\Desktop\imgwarp-opencv\imgwarp-opencv\src\CMakeLists.txt:2 (FIND_PACKAGE)

I am using Window 10, Visual Studio 2017. I have installed OpenCV properly and I can run some basic projects of C++ OpenCV that can be found around the internet.
I have also followed this video which shows How to Build Open Source Projects Using CMake and Visual Studio.
But, I can not run this project on my machine. I try File->Open->CMake to open the CMakeLists.txt which can be found in the downloaded repository, and I get this error:
CMake Error at C:\Users\Majid\Desktop\imgwarp-opencv\imgwarp-opencv\src\CMakeLists.txt:2 (FIND_PACKAGE):
By not providing "FindOpenCV.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "OpenCV", but
CMake did not find one.
Could not find a package configuration file provided by "OpenCV" with any
of the following names:
OpenCVConfig.cmake
opencv-config.cmake
Add the installation prefix of "OpenCV" to CMAKE_PREFIX_PATH or set
"OpenCV_DIR" to a directory containing one of the above files. If "OpenCV"
provides a separate development package or SDK, be sure it has been
installed.
I think I must extract the downloaded opencv-4.0.1-vc14_vc15.exe file somewhere in the project folder and link the CMakeLists.txt file (which one?) to the OpenCVConfig.cmake which is in the extracted opencv. Or maybe not.
I have also CMake gui and if I should run it that way I will appreciate that you explain it that way instead of using Visual Studio File->Open->CMake. No matter how, any way that helps me run this project is welcome. Please explain it step by step.
In one line (forget all the above): What should I do to run this project properly?

Not found Eigen3_DIR when configuring a cmake project in Windows

I want to compile an open project, it needs Eigen3, I followed its guideline but stuck in this step:
"Set environment variable Eigen3_DIR to {YOUR_EIGEN3_DIRECTORY}/eigen3/cmake."
I have installed CMake gui and it printed following errors after configuration
Make Error at src/CMakeLists.txt:15 (find_package):
By not providing "FindEigen3.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Eigen3", but
CMake did not find one.
Could not find a package configuration file provided by "Eigen3" with any
of the following names:
Eigen3Config.cmake
eigen3-config.cmake
Add the installation prefix of "Eigen3" to CMAKE_PREFIX_PATH or set
"Eigen3_DIR" to a directory containing one of the above files. If "Eigen3"
provides a separate development package or SDK, be sure it has been
installed.
But I have downloaded Eigen3 from here, and set the Eigen3_DIR as follows
So what should I do to fix it? I am just a beginner in cmake.
I am assuming you are using Windows. You will need Visual Studio installed. You can use the community version. You will need to do the following:
Create a directory called "build" within your Eigen directory.
Go to the build directory and do "cmake ..". This will create Visual Studio projects.
Load the .sln using Visual Studio.
Build the solution.
Ensure that the project called INSTALL was built also.
This will create the Eigen3Config.cmake file in your install directory. In my case the install directory was "C:\Program Files(X86)\Eigen3. Use this to as the value for Eigen3_DIR variable.
By default Eigen does not come with the Eigen3Config.cmake file. You will see Eigen3Config.cmake.in file. This is used to build the Eigen3Config.cmake file.
HTH

"CMakeLists.txt" seems to be missing

I was trying to build SFML in order to start developing 2d-games in c++. I put the source-code directory inside C: (the directory itself is called 'SFML'). while trying to generate .cbp files using CMake, I ran into an error:
"The source directory "C:/SFML" does not appear to contain CMakeLists.txt"
It seems like there is a missing file that CMake didn't create.
I am using Cmake 3.10.1, the installation file can be found in https://cmake.org/download/ under the title:"Windows win32-x86 Installer".
I tried to build SFML 2.4.2, using the generator of Codeblocks - MinGW makefiles. The version of codeblocks used is: codeblocks-16.01mingw-setup.exe, found in http://www.codeblocks.org/downloads/26
Did someone encounter the same problem before and knows how to overcome it? If not -
Is there an already-built, ready to use, libray of this version? (2.4.2)
If not.. do you know about a version of SFML that is usable in visual studio 2017?
And another question (That is the last one, I promise...) - maybe you can recommend me about another library for c++, that is usable to develop 2d-games?
edt:
note: I am completely new to all this building thing
the containments of SFML:
maybe it's the binary version?
lib contains some static libraries, bin contains some .dll s
You probably downloaded something wrong or potentially extracted the SFML source into a sub folder or something like that.
Since you've mentioned Visual Studio: SFML is 100% compatible with Visual Studio and you can build it from source any time without having to worry about dependencies (everything included in the repository).
The steps to compile are pretty easy. I'd recommend you install Git to clone the latest source from the SFML repository. In addition you'll need CMake, which you obviously got already.
Open a Command Prompt and change your directory to C:\SFML.
Clone the official repository using Git: git clone https://github.com/SFML/SFML.git source (note the trailing .)
Wait for the source to be checked out to the source sub directory.
Create a new directory called build: md build && cd build
Now invoke CMake, pointing to the source directory and also defining your install path: cmake -DCMAKE_INSTALL_PREFIX=C:/SFML ../source
Build and install a debug build of SFML: cmake --build . --target install --config debug
Build and install a release build of SFML: cmake --build . --target install --config release
Alternatively you can just open the generated Visual Studio solution and build the INSTALL project on your own.
(You shouldn't have to define a build tool or anything; CMake should notice Visual Studio being installed and pick it up automatically.)
I have experienced this using cmake version 3.10 when using the -S command line option. On cmake version 3.15.4 it behaves as expected - so if you update cmake then it might just work.
Note that the -S command line option was not supported before version 3.13:
https://cmake.org/cmake/help/v3.13/release/3.13.html#command-line
Normally cmake is called from a "build" subdirectory of a project root, the project root contains CMakelists.txt. So you would create a "build" directory, change to it, and submit "cmake ..". This would pull in CMakelists.txt from the project root, and use the "build" subdirectory that you are in as the build directory. We say "build", what it actually does is generate makefiles which can then used by the "native" build system (e.g. "make" or Visual Studio) to perform the actual compilation and linking. This arrangement is not always convenient, hence the introduction of the -S and -B command line options.