Recently I am about to learn mlpack. Today I have successfully built the solution from mlpack source code, but when I newly create a project I get the following error in the header file. I would like to know what is wrong and how to fix it.
errors
In the screenshot, the algorithm.hpp is under the build folder and its absolute path is D:\MLPack\mlpack\build\include\mlpack\core\std_backport\algorithm.hpp. The source code in the new project is just a copy from https://www.mlpack.org/.
The screenshot below shows some of the files generated after building solution of mlpack.sln.
generated libs
The versions of other libraries to help build the mlpack are :
Armadillo 10.8.0 (at least 9.800)
Boost (math_c99, spirit) 1.78.0 (at least 1.58.0, and I have added this version string in CMakeLists.txt before building mlpack)
CMake 3.20 (at least 3.6)
ensmallen 2.18.1 (at least 2.10.0)
cereal 1.3.0 (at least 1.1.2)
openBLAS 0.24.1
The configurations of my new project are shown below.
additional include directories
additional dependencies
post-build event
And I have also disabled "Conformance Mode".
disabled conformance mode
The entire building and using process refer to https://www.mlpack.org/doc/stable/doxygen/build_windows.html and https://www.mlpack.org/doc/mlpack-3.4.2/doxygen/sample_ml_app.html.
I finally found out that this problem seems to be related to the version of the source code. I should not use the latest version of the source code from https://github.com/mlpack/mlpack, but the source code corresponding to the latest stable version. After I replaced the include directory with the include directory corresponding to the officially released windows installation package, no error was reported during the building of the solution in my new project, so I got the expected result.
the result
This incident taught me a lesson that I should use the stable rather than the latest version of the source code when doing CMake in the future.
Related
I'm trying to use OpenCV with Dear ImGui in Visual Studio 2022. I'm new to C/C++ libraries and building in general, so I'm unsure if I'm doing anything right. ImGui uses 32-bit architecture and I've used Cmake gui to compile the source code as Win32. I think I have the compiled source code, but it seems to be different than downloading the pre-built libraries. File Explorer Screenshot. I've added the bin to PATH environmental variable, and in Visual Studio tried adding \include to Include Directories, \lib or \lib\Debug to Library Directories, and opencv_world460d.lib to Additional Dependencies. The program still runs, but it doesn't seem to include anything related to OpenCV in the #include files. I found a few .dll files in bin\Debug, but I'm not sure if I should bother with that. I think I could move the source code into the project, but I'm fairly certain that isn't the proper way to do it. Any help would be appreciated.
I needed to run the install target:
You may have built the project, but probably you didn't run the install target. Try running cmake --build <build_dir> --config Release and then cmake --install <build_dir> --config Release, where <build_dir> is a placeholder for the path to the build dir shown in the screenshot. The latter command probably requires admin privileges. Probably best to check the docs of the lib, if there's a step by step instruction for building & installing the whole thing. –
fabian
Background
I have big project which builds runs on windows perfectly.
When some changes are applied in CMakeLists.txt and project is build, Visual Studio project is properly updated.
Xcode version: 10.0 (10A255) or 10.1 (10B61) (tested on different machines).
CMake version: 3.12.2 or 3.13.1
Problem
Problem appears when same project is build on Mac OS for Xcode.
After configuring CMake:
cmake .. -G Xcode
Generated project works fine, everything builds properly and test are passing.
Now when CMakeLists.txt files are modified (when developing project or when fetching new changes from repository) and ZERO_CHECK or BUILD_ALL are selected, build doesn't lead to Xcode project update.
Invoking cmake . doesn't detect changes too.
Workaround
The best workaround I've found is deleting everything two files: cmake_install.cmake and CMakeCache.txt. Then rerun command which generates project cmake .. -G Xcode.
In this scenario whole detection is redone from scratch, but at least build doesn't start from zero (unchanged files are not recompiled).
This is painful, since lots of manual stuff must be done, and project have to be recreated and this consumes time.
Hints
In some previous project I had similar problem, but it was happening only if maven was detecting updates for dependencies, so it happened quite rarely. When it happened I just called touch CMakeLists.txt and build again and this workaround was fine. This solution doesn't applies since every build has this issue.
I was suspecting that protobuf generation procedure has something with it, but when I've disabled it problem still persists.
I've tried to provide complete minimal example, by creating simple project file, but I was not able to reproduce the issue. For all other projects it just works, so system configuration is not the issue.
Questions
How can I debug project generation process when running cmake to find source of this problem?
Is this a known problem?
Is there a better workaround which will not lead to full rebuild regenerating project file (which also involves detecting system capabilities)?
Is this a known problem?
Over on the CMake Discourse, Craig Scott (one of the CMake maintainers) has commented on a variant of this bug as a known architectural limitation of Xcode:
With the Xcode generator, targets have a dependency on the ZERO_CHECK target, which is what re-runs cmake for you automatically if something changed. But the problem is that the rest of the build in that run still uses the old details from before cmake . gets run. If you build again, that rebuilds anything whose details changed, but explicitly re-running cmake . first if you know something about the project changed will be more robust and probably avoid more unnecessary rebuilds.
-- https://discourse.cmake.org/t/documented-criteria-for-build-correctness/3087/2?u=alex
Your comment that "invoking cmake . doesn't detect changes" is strange in light of this, but it could be that old CMake versions, like 3.12 and 3.13 which you were using when this question was asked, had a bug that has since been fixed. It could also be something project-specific that we can only guess at. Missing a CMAKE_CONFIGURE_DEPENDS directory property? Have a bad set(... CACHE ... FORCE) call? Can't say...
When I try to compile individual build targets from project imported via CMakeList.txt I get error saying that file cannot be found. The error message cite path which is doubled the true path:
the propper path should be:
/u/25/prokoph1/unix/git/SimpleSimulationEngine/cpp/build
(this is computer in university network which could mess path a bit)
Background: I'm have big CMake C++ project (https://github.com/ProkopHapala/SimpleSimulationEngine) with >100 nested build targets. Up to now I was using Code::Blocks generator, now I'm trying to Kdevelop4 which looks pretty cool. It is able to load CMakeList.txt without any project-generator. The code navigation (Jump to declaration) works very well. It can compile the whole project without any problem. But compilation and running individual build targets does not work.
KDevelop 4 is unmaintained anymore.
You should use KDevelop 5.
If your distribution does not provide a fresh version, I suggest using the AppImage from https://www.kdevelop.org/download
I am trying to cross compile an application for a different platform (quark processor) using cmake. The platform has provided an SDK to me. My application requires a newer version of one of the libraries in the SDK. I have added the new source code for the library using add_subdirectory(). But my problem is when I use target_link_libraries(), cmake is linking the older version of the library in my SDK. How to enable cmake ignore the library version in the SDK sysroot, and only use the new library version present in the subdirectory?
Edit: My apologies for the initial lack of details.Adding more details to the question as suggested.
My CMakeLists.txt include the following statements
add_subdirectory(libs/mosquitto-1.4.10)
target_link_libraries(myapp mosquittopp)
As mentioned, my problem is that the SDK I am using contains a 1.4 version of mosquitto library. The target_link_libraries() only links the 1.4 version and not the newer 1.4.10 version, even though cmake successfully builds the 1.4.10 version.
I'm following a book written for the older version of OpenCV (OpenCV 2 Computer Vision, by PACT) and it tells me to include the lib folder in my Visual Studio 2013 Property Manager when creating a new property sheet.
I don't see a directory called lib in the current GitHub version (opencv-master, which is OpenCV 3.1.x). Has this folder been replaced by something else?
I built OpenCV with cmake. I found a 4 year old unanswered question wherein someone was also looking for this folder. They tried building the library from another directory that no longer exists, but that didn't work for them anyway...
Another OpenCV user just told me that GitHub doesn't include the libraries, so you have to cmake them locally. I'm still not clear on where / how I can cmake them.
I realize the pre-built binaries have this, but I'm avoiding them because I need the SURF functions in opencv_contrib, so I needed to build it from source.
The pre-built binaries will have a library folder in the corresponding path
Local System Path(Opencv Folder)-> build->x64/x86->vc10/vc11/vc12->lib.
As you mentioned that you don't wish to use it then the only option left for you is to build it locally which is a much better option if you plan to use Opencv libraries for varied functions and projects as it resolves many build errors that you might face later.
I used the Cmake Graphical user interface to build opencv, following are the steps I followed to successfully build the libraries on my system .
So, you would need to create a new folder that will contain all
the Makefiles generated.
Please refer to this image for clearer understanding:
In GUI you define source directory path where OpenCVConfig.cmake is present, according to your image it's the
current folder in your image opencv-master.
Similarly, define the path to the new directory you created where all the build files would be stored.
Make sure to uncheck Build_Examples to avoid configuration errors.
Then click Configure at the bottom when configuring is done .(you may need to configure it twice)
After click the tab adjacent to configure, Generate to create the solution file.It will ask you for the compiler name
select the
compiler installed on your system from the list of choices. After
generation is done.
Go to this path Build_New_Directory(the directory you created) you will find OpenCV.sln build this project, it will take around 10-15 minutes depending on your processor, wait patiently .If you get a build error at this point don't invest your time in debugging on Visual Studio go back to Cmake GUi and configure it again and this time give the path to dependent libraries on your system that it could not find .Repeat the process it should be successfully build now.
After it is successfully build you can now locate the path of all opencv libraries build on your system as follows.
Build_New_Directory(the directory you created)->
install->x64->vc10(compiler I used)->lib.
As an update to Nikita's awnser:
There is a cmake build bug where the x64 folder will not be created if OpenCV_RUNTIME is not set. This will happen if you build an old OpenCV (e.g. <= 3.2.0) with a newer Visual Studio Version than was available at that time (e.g. Visual Studio 2017)
To fix this, add the correct MSVC_VERSION elseif-cases in both ./cmake/OpenCVDetectCXXCompiler.cmake and the ./cmake/templates/OpenCVConfig.root-WIN32.cmake.in (or ./cmake/OpenCVConfig.cmake in < v3.2.0) files:
[...]
elseif(MSVC_VERSION EQUAL 1900)
set(OpenCV_RUNTIME vc14)
# old version ends here with endif()
elseif(MSVC_VERSION GREATER 1909 AND MSVC_VERSION LESS 1920)
set(OpenCV_RUNTIME vc15)
elseif(MSVC_VERSION GREATER 1919 AND MSVC_VERSION LESS 1930)
set(OpenCV_RUNTIME vc16)
endif()
[...]