I have compiled opencv3.4.0 with cuda9.1 support using CMake on Windows 10:
and then I built the INSTALL file in visual studio 2015 in OpenCV.sln.
But this is my Release folder:
The file opencv_cudaoptflow340.lib is not anywhere in C drive, however it should be in C:\opencv_3.4.0\opencv\build\lib\Release. How can I build opencv so that these library and dll files are generated?
You build opencv_worldxxx.lib all is inside as well in opencv_worldxxx.dll. You can unmark the option in Cmake related to opencv_world library. Than the libs and dll will be in separate files. Marked world all is in that single file. Unmarked option generates opencv_core opencv_videoio opencv_ml .lib .dll. You can decide one or another. There is difference in link one library or several libraries and consider this in packaging of your app. build in Cmake
Related
I'm attempting to use OpenCV for Windows as supplied by opencv.org in a project I'm building with JetBrains' CLion IDE. I've installed the opencv library and configured CLion (set(OpenCV_DIR) to reference the build directory under it, but CMake issues the warning:
Found OpenCV Windows Pack but it has no binaries compatible with your configuration.
You should manually point CMake variable OpenCV_DIR to your build of OpenCV library.
I've tried some of the older distributions from opencv.org with the same results. It appears CMake is locating the OpenCV libraries, but doesn't want to use them. Why, and how do I get the OpenCV libraries to work under CLion?
The short answer is, you will probably need to build OpenCV from source in order to use it with CLion. But given the number and range of partially answered and unanswered questions here* and elsewhere on using JetBrains' CLion IDE with the OpenCV library, I think an overview is needed (my notes are from CLion 2016.3 and OpenCV 3.1, YMMV):
Though not produced by JetBrains, CMake is very central to CLion's operation. Understanding CMake therefore helps greatly in diagnosing CLion build problems. In particular CMake maintains a disk "cache" of settings which you may need to clear to incorporate changes to your environment (Tools->CMake->Reset Cache and Reload Project).
To make use of OpenCV in your build you must specify it in your project's CMakeLists.txt file. You request that CMake locate your OpenCV location and link it to your TARGET. An example of a sequence of commands from CMakeLists.txt for an executable named mushroom follows:
add_executable(mushroom ${SOURCE_FILES})
FIND_PACKAGE(OpenCV REQUIRED)
TARGET_LINK_LIBRARIES(mushroom ${OpenCV_LIBS})
(For more on FIND_PACKAGE, see CMake:How To Find Libraries.)
FIND_PACKAGE for package XXX works either by way of FindXXX.cmake files located at CMake's Modules directory, or by consulting environment variable XXXX_DIR. On my system, no FindOpenCV.cmake file was present, so I relied on the OpenCV_DIR environment variable instead. This must be set, not to the root of your OpenCV installation, but to the build folder beneath it. I used an entry in CMakeLists.txt to set this variable, e.g.:
set(OpenCV_DIR C:/Users/myacct/AppData/Local/opencv-3.0.0/build)
To link with OpenCV, CMake uses either FindOpenCV.cmake or OpenCV_DIR (see previous point above) to locate a file named OpenCVConfig.cmake. This file is generated by and ships with a particular build of OpenCV in order to document what components are present and where they are located.
Problems may occur when variable names used by OpenCVConfig.cmake conflict with those CLion has stored in its environment. In particular, if your OpenCV was built by Microsoft Visual C (MSVC), as is the Windows distribution from opencv.org, it won't work with CLion.
Because CLion's build toolchain (ControlAltS-toolchain) uses either MinGW or Cygwin, OpenCVConfig.cmake will search for OpenCV binaries under a subdirectory named mingw or cygwin and will find none because the binaries were built with MSVC (it will look in a directory like vc11 or vc12 instead). This probably means you will need to build OpenCV from source in order to use it with CLion.
Would reconfiguring OpenCVConfig.cmake to point to the MSVC binaries make this work? you may ask. Unfortunately the answer is still no, because libraries built with one compiler typically cannot be linked with another one.
OpenCVConfig.cmake or FindOpenCV.cmake likely contain diagnostic messages, but when CLion executes CMake for you, message(STATUS) calls are not displayed. To make them display, change them to message(WARNING) or message(FATAL_ERROR). But CLion 2016.3 EAP relieves this problem; see https://stackoverflow.com/a/39398373/5025060.
CLion does not indicate which .cmake script issued which diagnostics; don't assume they all come from the same script.
Hopefully this provides some general guidance on resolving CLion / CMake / OpenCV compatibility problems. Note that this does not cover compiler or linker issues; these will not appear until CMake completes its initial makefile build. Compiler or linker issues occur at a later stage and are controlled by include*(), link*() and other commands in CMakeLists.txt.
*Some related SO questions:
OpenCV Windows setup with CLion
OpenCV CLion (Cmake) linking issue - cmake reports a strange error
use OpenCV with Clion IDE on Windows
Compiling OpenCV on Windows with MinGW
Could not find module FindOpenCV.cmake ( Error in configuration process)
CMake: Of what use is find_package() if you need to specify CMAKE_MODULE_PATH anyway?
For using CUDA, I need to compile OpenCV. I'm using CMake and OpenCV 3 sources. I do not get any errors when clicking und "Generate" in CMake. Then I compile the OpenCV.sln solution for Win64 using Visual Studio (I selected the right visual studio version). I do not get any errors when compiling.
But I do know what to include; normally, there is "opencv" and "opencv2" in the include folder. But this does not exist.
My opencv folder after compiling:
My include folder:
Includes located in sources folder, not in build folder (if you did not Build INSTALL project).
I've written some Delphi code I would like to share on GitHub. All code is contained in runtime and designtime packages as required. There are many "Project Options" to set for each project. (Output directories, search paths, compilation options, etc.) I've managed to find some default options that work well for my situation but reading other Q&As here it's clear there are multiple ways of working.
What project options should be used to allow the open source packages to easily be incorporated into individual projects?
I've recently started using NodeJS. The NPM package manager makes it super easy to use third-party packages in a project. Packages are installed with one simple command on the command line. Packages will automatically install any required dependencies.
PS: Feel free to edit this question if you would like to add extra things to consider.
Let's say you have this structure
MyComponent
Packages
DelphiXE7
Package2.dpr
source
bin
Delphi XE7
then set
Search Path
..\..\..\source
Unit output directory
..\..\..\bin\Delphi XE7\$(Platform)\$(Config)
After compilation for all supported platforms and both Release and Debug you will have this structure in the bin directory
MyComponent
Packages
DelphiXE7
Package2.dpr
source
bin
Delphi XE7
Android
Release
Debug
Win32
Release
Debug
Win64
Release
Debug
For installation you have to setup some path inside the IDE.
Environment
MYCOMPONENT => [root path to the files]
Library
Repeat that for all supported platforms
Library Path
$(MYCOMPONENT)\bin\Delphi XE7\$(Platform)\Release
Search Path
$(MYCOMPONENT)\source
Debug-DCU-Path
$(MYCOMPONENT)\bin\Delphi XE7\$(Platform)\Debug
If there are some language related units there is also a place to add (see Library - translated)
This ensures, that you have full debug feature (with Use Debug-DCU option set) and on release you have no debug code in your application.
Just a sidenote on libraries you should not want to install because you only use them in some projects.
Simply use the Optionset combined with a environment variable.
Here my SuperObject.optionset ($(USRLIB) points to a directory, where I collect all common used source code. And $(USRLIB)\ext is the place for all of the external libraries).
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<DCC_UnitSearchPath>$(USRLIB)\ext\superobject;$(DCC_UnitSearchPath)</DCC_UnitSearchPath>
</PropertyGroup>
<ProjectExtensions>
<Borland.Personality>Delphi.Personality.12</Borland.Personality>
<Borland.ProjectType>OptionSet</Borland.ProjectType>
<BorlandProject>
<Delphi.Personality/>
</BorlandProject>
<ProjectFileVersion>12</ProjectFileVersion>
</ProjectExtensions>
</Project>
To use the superobject library I simply add the optionset to the project (right mouse click on build configuration) and everything is fine.
I'm starting with Delphi XE5 and I would like to split my application in one exe and multiple reusable libraries. That means I don't want to split the running *.exe application in DLLs or runtime Packages.
To achieve this, I have seen that in delphi we can create runtime packages and I followed the following steps:
I have created a new VCL Forms Application project (EXE project).
I have added a new Package project (BPL project) to the project group and I have modified its project options to set usage options to 'Runtime only' and build control to 'Explicit rebuild'.
I have added a dependency betwen the EXE project and the BPL project (EXE project depends on BPL project).
Finally I have compiled the BPL project and added the generated DCP file as a runtime package in the EXE project (Project options/Package/Runtime Packages).
But when I add a reference on the EXE project to use a module (moduleX for example) from the BPL project, compiler give me an error like this:
[dcc32 Fatal Error] ModuleX.pas(7): F1026 File not found: 'C:\DDDProject\MyEXEProject\ModuleX.dcu'
If I mark as checked the 'Link with runtime packages' option in the EXE project (MyEXEProject) the solution compiles without errors but I can't run or debug the application.
Please, can anyone help me?
I don't want to split the running *.exe application in DLLs or runtime Packages.
Runtime Package BPL files are DLLs. That is what allows them to be shared amongst multiple EXEs. They are just normal DLLs with special VCL/FMX handling built in.
When you enable the "Link with runtime packages" option, you are linking the EXE file to your BPL file (or DYLIB or SO file, if compiling for platforms other than Windows), so you MUST distribute the BPL file (and any other BPL files it depends on, like rtl190.bpl and vcl190.bpl) with your EXE file. So they have to be in the EXE's folder, or at least in the OS search path, in order for the EXE to run.
When you disable the "Link with runtime packages" option, your package's code is statically linked directly into the EXE file, so you need to make sure the EXE project's search paths include the folder were your package's DCU file(s) are located.
If you want to create a reusable library but not a BPL, then create a Static Library (a LIB file) instead of a Runtime Package. You can then add the LIB file to multiple projects as needed.
I am compiling OpenCV for our project with specific build options (such as 64bit, QT and OpenNI). I was able to follow the instruction as given here: http://opencv.itseez.com/doc/tutorials/introduction/windows_install/windows_install.html
At the end of 2-3 hours of build process, I ended up with \install\build\ with collected bins, dlls and libs in their respective folder. I would like to distribute an .exe installer to other members in research group. But I could not because _CPack_Packages/win32/NSIS is nowhere to be found.
Note: To create an installer you need to install NSIS. Then just build the
Package project to build the installer into the
Build/_CPack_Packages/win32/NSIS folder. You can then use this to
distribute OpenCV with your build settings on other systems.
In the cmake-gui screen, I ticked "Build Package" which I hoped would enable me to see Build/_CPack_Packages/win32/NSIS folder. After build process, this is not found.
Could someone give a suggestion as why I don't see this _CPack_Packages/win32/NSIS folder as described? Could I use
Inno setup instead? If so, do I simply pack all \build\install folder and set path in system to include \build\install\bin?
Thank you.
Sticking with the KISS principle (Keep it simple, Stupid!):
Did you install NSIS prior to building the Package project?
INSTRUCTIONS TO BUILD WIN32 PACKAGES WITH CMAKE+CPACK
------------------------------------------------------
- Install NSIS.
- Generate OpenCV solutions for MSVC using CMake as usual.
- In cmake-gui:
- Mark BUILD_PACKAGE
- Mark BUILD_EXAMPLES (If examples are desired to be shipped as binaries...)
- Unmark ENABLE_OPENMP, since this feature seems to have some issues yet...
- Mark INSTALL_*_EXAMPLES
- Open the OpenCV solution and build ALL in Debug and Release.
- Build PACKAGE, from the Release configuration. An NSIS installer package will be
created with both release and debug LIBs and DLLs.
Jose Luis Blanco, 2009/JUL/29
I suggest instead of using Visual Studio to build, you should try using CMake.
http://www.cmake.org/
Let me know if this helps at all.