I've been trying to integrate OpenCV's C++ library with my own C++ code (not involving Python), with the additional contrib modules (meaning I have to compile OpenCV myself), for multiple platforms, and I got stuck on CMake for so long it made me question if I was just a total idiot and should give up on programming forever.
Using OpenCV was just a matter of
find_package(OpenCV 3.3.1 REQUIRED)
target_include_directories(theApp PUBLIC ${OpenCV_INCLUDE_DIRS})
target_link_libraries(theApp PUBLIC ${OpenCV_LIBS})
Will this include the contrib modules even for Android? And iOS?
Once I sat down and read the Cmake basics, yes, it was easy enough to get OpenCV working with basicallly the code you posted, except I couldn't find a way to include the contrib modules in an Android version, it would always complain Aruco wasn't there.
Until I went and compiled OpenCV myself, and that was the part that was a massive pain in my ass - CMake failing to include architecture information in the library files unless you specify it on the command line before running Cmake GUI, even tho it is an option in the GUI. Tho perhaps that's more of a failing of the OpenCV build script than Cmake itself?
I did just recompile OpenCV myself, so I did get there in the end and it's all working now, but I'm sure I'll be tweaking all parts of this project for months to come so if there's an easier/proper way, I'm happy to learn.
It also needs to be statically linked.
Note: I'm not a real programmer, I don't know enough to have even been able to get an entry level job in the industry yet, I'm an idiot that doesn't belong on this website. I'm just trying to learn as I go.
Some things will get easier with time, and a lot of other things are going to suck shit forever. Keep on truckin'!
Those times coincide with projects that fail to follow the "modern Cmake" style, based on build targets instead of pretending Cmake is a scripting language.
Keep in mind that modern Cmake style is a thing since the release of Cmake 3.0, which was what? A decade ago?
If developers who don't know better end up writing messy unmaintainable code, their code is an unmaintainable mess. That's not a result of their tech stack, but their own work.
To be honest I think alot of my frustration was with the OpenCV build scripts rather than Cmake itself, but I don't love Cmake either.
If this worked on desktop, I would assume this to be a bug in the OpenCV cmake files, there's no reason for aruco not to be in OpenCV_libs if my understanding of the OpenCV build system is correct (but then I did not really have to fight it)
Still, even tho it was frustrating and felt like a waste of time, learning to compile a big project like OpenCV taught me alot, and all or part of that will probably be useful in the future anyway :) even as a dot point on a resumé
It improved my shell scripting skills, and helped me understand how C++ links, and what library files actually contain etcetera
Whether cmake is good or bad, and whether it was necessary for my project or not, now I have successfully used Cmake to compile a big library!
I have to statically link it anyway, so compiling OpenCV separately and manually allows me to cut it down and make build changes etc that might be useful, as well as forces me to look at how it's structured and understand it better.
Thanks for your help!
That is exactly what that is. Cmake is extremely powerful, and it lets library authors make build configuration that is quite often too flexible. Combine that with no standardized package manager for c or c++ for decades, and much cmake evolution over that time, means you encounter many different ways to solve problems.
Opencv is up there for most complex cmake projects. Only behemoths like VTK, ITK, and ROS beat it in complexity of the build.
Also, don't beat yourself up too much. :)