Clarification of steps while generating of OpenCV libraries using CMake - c++

I have generated the OpenCV libraries using CMake a couple of times using tutorials available online, albeit without completely understanding the process. Here is the process that I follow
Configure CMake to build the OpenCV binaries (eg with QT, TBB, without CUDA, OpenCL etc)
Generate the binaries using CMake
The folder where the binaries are built has a number of .sln files. I open the file OpenCV.sln and run the project ALL_BUILD for both Debug and Release configurations.
There is a new folder created. bin which contains the libraries (both .lib and .dll for the release and debug versions.
(Optional) Sometimes I have also build the project named INSTALL (in the same solution), just out of curiosity. I noticed that it creates another folder, that contains the library files in almost the same pattern as the prebuilt libraries that come with the OpenCV package. Interestingly, my programs in MSVC or Qt work equally well if I link with either the libraries in the install folder or the bin/lib folder.
My questions are
What is the function of the install solution?
How are the libraries generated by the install solution different from the ones found in the bin and lib folders?
Why is the install solution not built when the ALL_BUILD solution is built

What is the function of the install solution?
It packages/collects the build output into a portable set of libraries and headers that you know you can move around in your pc, or to another machine.
How are the libraries generated by the install solution different from the ones found in the bin and lib folders?
They are not. You have probably built first shared and then (by reconfiguring with cmake) static libraries, but than the target install only installs the one you have currently selected (in your cmake-gui?)
Why is the install solution not built when the ALL_BUILD solution is built
install is a special target for cmake. In fact, by default install triggers all and only actually executes when all has successfully terminated, but the viceversa is not true.

Related

Compiling and Linking to Visual Studio 2022 using OpenCV source code built as Win32 from CMake C++

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

vcpkg manifest install system wide

Just tried Vcpkg Manifest on my cmake project and it is cool, with exceptions however.
My project depends on opencv and it takes a long time for vcpkg to install opencv. So I realized I don't want vcpkg downloawding/installing opencv every time I clone the project in a different folder.
Is it possible to use Vcpkg Manifest but make it install libraries system wide instead of locally to the project?
Or at least not inside the build directory, so will be possible to reuse it?
No, you can't install libraries system-wide in manifest mode.
But binaries are cached so that if you use a library in multiple projects, you don't have to build it from scratch.
https://github.com/microsoft/vcpkg/blob/master/docs/users/binarycaching.md
I abused vcpkg's --x-install-root to achieve similar results as manifest mode.
--x-install-root= (Experimental) Specify the install root directory
Under your project folder, you can install this project's dependencies into a system global directory by using this parameter, so that all projects can share the installed packages system wide. For example, in my case, I installed all packages into $VCPKG_ROOT/installed directory like this:
vcpkg install --x-install-root=$VCPKG_ROOT/installed
You can even use vcpkg list anywhere if you (ab)use it this way.

Where do I find the library's files after building Polycode with MSVC 2013?

I downloaded the polycode-master from Github
I ran cmake as suggested in the BUILD.md
And then I built the ALL_BUILD project from the PolycodeDependencies.slnwith MSVC 2013
Where do I now find the DLL and LIB files and how do I set up a new Project to use Polycode?
EDIT: I now headed over to http://polycode.org/download/ and downloaded the zip-file with the binaries but I still dont know how to use them...
After you've built the Dependcies you need to build the real Polycode stuff - that's described a bit further down in Build.md.
After you've built ALL_BUILD in the Polycode.sln you'll find the C++ libraries in Release/Windows/Framework/Core/lib.
To use those libs you might want to start with the Examples in the Release/Windows/Framework/Examples folder.
To start your own project either use the Template in the Template folder or use the PolycodeProjectGenerator (disclaimer: I'm the author of the last one)
Hope this helps a bit..
Oh and don't forget to build the install targets of dependencies and Polycode!
Look at the build directory you specified when running cmake. There should be a subfolder called bin or something similar that has the binaries.

Generate a redistributable project with CMake

I'm looking for generating a redistributable project for Windows and Linux using CMake as project configuration system and gcc-4.8 / VS2012, plus extra thirdparty libraries like Qt5. How can i create a package with all the needed dependencies and make the project running on other machines, without installing on those machines the required packages (i.e. Qt5 setup)?
EDIT
Googling heavily i've found Qt5 requires some files and i've found this discussion
Application deployed with QT5 libraries does not start on Windows 7
which explains the required Qt5 dependencies.
Normally, I would use install to list the desired files and CPack for packaging them. That is, suppose I'd like to create a package consisting of the following components:
my_nifty_library.dll
my_nifty_executable.exe
QtCore.dll
QtGUI.dll
(Disclaimer: I'm not Qt expert so the last two files might not exist at all, but you get the idea.)
Given that both my_nifty_library and my_nifty_executable are part of your project, you have control over them, so simply do the following:
install(TARGETS my_nifty_library my_nifty_executable
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib)
Now, since Qt won't be built as part of your project, I suggest you use the ExternalProject module.
Now, you can use CPack and create, say, a NSIS installer or a tar.gz out of the installed files.

How to include boost::filesystem into a VS2010 project without adding a dependency on bjam?

According to this answer, the intended way to include non-header-only parts of Boost into a Visual Studio 2010 project require the use of bjam to build the correct libraries.
What is unclear to me is whether this is a one-time-only thing, where I just check in the lib files produced by bjam, or whether anyone who wants to build my project will from now on require not only Visual Studio but also bjam.
The project only targets Windows 32-bits, because it builds a plugin for a program that's only available in this configuration, and only needs to support the statically-linked multi-threaded CRT.
(For the record, if I just include the relevant .cpp files into the build, the compile stage succeeds, but at link stage I get a missing library error, which is apparently caused by the "auto-link" feature. Perhaps I should just disable auto-linking, if it's possible?)
You don't need bjam. Like yasouser answered, you can download the installer from boost pro, the downsides being that
you need to register though that's quick and easy
it's usually/sometimes a release or two behind the latest boost release.
What is unclear to me is whether this is a one-time-only thing, where I just check in the lib files produced by bjam, or whether anyone who wants to build my project will from now on require not only Visual Studio but also bjam.
It is a one time thing per machine. Once you have the boost binaries you don't need bjam anymore. The nice thing about the installer is that you can install some selected versions of the boost libraries + the headers (You can select VS version, single-threaded, static/dynamic, etc. on a per library basis e.g. thread, system, etc.) and then at a later point you can just run the installer again and add other binaries.
So if you're auto-linking and are missing a specific lib, just run the installer again.
FYI, you can disable boost's autolinking option by defining BOOST_ALL_NO_LIB and then manually linking in the lib versions you want.
Some of the boost libraries require you to build them as static or shared libraries and link them in your project. Either you can download the source and build it for yourself using bjam or you can install the pre-built binaries from here.
Yes this is a one time install (if you are installing from pre-built binaries or built by yourself). And those building your project will also need to do the boost install once for them to be able to build your project.
if I just include the relevant .cpp
files into the build
Direct including cpp files has many drawbacks. The only reason of borrowing .cpp files I can imagine is to allow build the project on other PCs without installing boost there. But I think it can be solved by distributing particular boost .lib files as well.