And when trying it out, remember: CMake is a build system with the goal of configuring the build, so that the compilation can run without problems. In a properly set up and syntactically correct CMake project, it should be impossible to have a compiler error, as every misconfiguration would be detected and corrected by CMake, or printed out in a helpful error message. Thus, any compiler error that could be prevented by CMake is to be discussed here.
Here are some stats from my testing:
On Windows 11, Visual Studio Community 2022:
2 out of 10 unit tests fail, does not seem to be a CMake issue
6 out of 161 examples fail, does not seem to be a CMake issue (seems to be assimp and opencv)
Visual Studio Code and CLion are exactly the same as it’s the same toolchain and MinGW is not implemented yet
Ubuntu 22.04 (GCC11)
All examples build and all unit tests pass IIRC
Any other platforms and compilers are still entirely untested
Feel free to comment, let’s have an open discussion here!
downloads the libs, and processes most of the stuff but blocks at:
CMake Error at examples/CMakeLists.txt:16 (add_executable):
No SOURCES given to target: 3DModelLoaderExample
Call Stack (most recent call first):
examples/3d/3DModelLoaderExample/CMakeLists.txt:1 (define_example)
CMake Error at examples/CMakeLists.txt:16 (add_executable):
No SOURCES given to target: assimpExample
Call Stack (most recent call first):
examples/3d/assimpExample/CMakeLists.txt:1 (define_example)
simply removing the examples lines from examples/3d/CMakeLists.txt gets us to
CMake Error at addons/ofxOpenCv/CMakeLists.txt:2 (target_link_libraries):
Target "ofxOpenCv" links to:
of::opencv
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
Not sure why there are no sources on macos, never had that issue. Gotta look into it later. As to the opencv error, this means that the CMake target for opencv is not found.
Please check if it exists in the downloaded package from the apothecary. If yes, it is not imported correctly. If not, a find_package(OpenCV) must be added to find a system package, like most packages in Linux are.
Can you please download the windows/visual studio ones amd check for any inconsistencies? I would assume that the folder names are not exactly the same, this is the biggest issue with all of this, that all apothecary packages are so freakin inconsistent. I had to get a baseline working and then add tons of exceptions for specific packages.
You can add diagnostics yourself by going into the cmake folder and into the scripts (download_and_link_deps, import_deps, etc), and in the CMake file you can add a print statement like this: message("Variable: ${VARIABLE_NAME}"). There are many functions to look at, one is called for every downloaded archive, wich calls a function for every folder in the archive, which calls a function for every binary in the folder, and so on.
If i see correctly there’s not an opencv folder, but opencv2 and opencv4, right? Which one should be used? Is there any reason to use 2?
If 4 is to be used, my approach would be to modify the function that is called for every folder, and when the package is called opencv4 and the platform is macos, rename it to just opencv.
Another, easier but less consistent approach would be to keep everything, but if on macos, link to opencv4 instead of opencv. Please try to modify ofxOpenCv to link against of::opencv4 instead. If all my assumptions are correct, this 4 should be the only change to make it work on macos. (although break on others)
Also, this whole approach to scan the apothecary is a really ugly workaround because we need to make something consistent we have no control over.
Do you think it would be accepted to include cmake files in the apothecary? This would make things a million times easier, as instead of writing 1000 lines of exceptions, you can simply add_subdirectory the apothecary, and itself imports the libraries for you, as itself knows best which files it includes. Every apothecary would have one CMakeLists with a list of its own files.
EDIT:
With this approach, all of the current problems would simply disappear, as we just include the macos apothecary’s cmake file, and it defines a target called opencv which links to libopencv4.a. Very simple
I am not familiar with the apothecary area so I cannot comment.
likewise as to why the opencv2 stuff is in there. there is an opencv folder, which contains a single set of libraries, but with 2 and 4 includes (and the 4 includes 2… see screenshot).
I tried changing the link to target_link_libraries(ofxOpenCv of::opencv4) but get a similar error:
CMake Error at addons/ofxOpenCv/CMakeLists.txt:2 (target_link_libraries):
Target "ofxOpenCv" links to:
of::opencv4
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
the structure of the downloaded libs are pretty different. macOS filesystem case sensitivity is an issue that pops up once in a while (ex: ofxDeckLink vs ofxDecklink), but in the case of opencv everything seems constant.
I am also attaching the tree of the build folder, in case it reveals something.
hmm that seems to be correct, as the name of the cmake target is derived from the root folder name and the include folder is added to include and any libraries found recursively are linked to it. It should actually work.
Can you please check download_…_deps.cmake if the correct package for macos is even downloaded? i suspect that i forgot to download all 4 packages…
The archive gets downloaded to build/_deps/…_src, so you see what’s actually available
Finally got some time to look into it, i see immediately what’s wrong. The osx4 archive is completely inconsistent, it has a completely different file layout, even compared to osx1 to 3. This will be such a mess to once again fix the inconsistency in CMake…
Alright, so it should be fixed now. There is a workaround in place for the osx4 package. Also, your first error was because it seems like during development just yesterday, these examples were removed from OF and after merging into my fork, only CMakeLists remained without any source files. Both should be fixed now
EDIT: I also added a note into cmake.md how to set the target platform manually in case cmake cannot determine it or it is wrong
make gets some errors (I’m attaching the output as a text file as it is a bit long). the evident ones are that it’s looking for GLUT (should not, on macOS), and Objective-C native classes are not recognized.
First of all, what is exactly the case with glut? I think someone mentioned that it is not really used, but it was needed to compile, so on windows i just cloned the repository in cmake. not sure if this was the right approach but is it really in use, despite not being in any apothecary?
And second, i suspect that it has to do with ofAVFoundationVideoPlayer. I had to include ofConstants in order to do the #ifdef for platform conformness, and in order to include orConstants i had to change the file from being an objc file to an obj c++. It was the only file in the entire framework being c or objc anyways, so another inconsistency to eliminate. I basically changed all occurrences of the file in all project files to objc++. Is there a reason it must be objc? What’s strange is that it worked in the automated CI build, so no idea why it would suddenly be an issue for you despite not even using the macos project files
well unfortunately (apart from what searching the forum might reveal) I don’t know the reason why GLUT is not used on macOS (I don’t think it’s specifically an OF thing).
about why ofAVFoundationVideoPlayer is .m and not .mm I cannot say it if’s an inconsistency or a design choice but FYI the iOS tree has a bunch of .m and .cpp that are treated as .mm by Xcode.
I can only say so much that i wanted to add the #ifdef in the source file, so its consistent with anything else. I had to change it to mm because including ofConstants is necessary, and it complains that it can’t find the cstdio header which is included in ofConstants
OK i’m subscribed to this thread so i’ll get notified if something else pops up but feel free to DM me when you have further specific macOS/iOS tests you want to conduct.
did it work out for you in the end? i thought there were still errors… Unfortunately i have no way of testing on macos and i haven’t managed to set up a VM yet, so its relatively hard to diagose any issues. glut should be easy to fix if i know which one of a few issues it is, not sure about the .mm thing as i haven’t had any issues since i changed the file ending
yes still errors; current status is: the CMake step completes, but the Makefiles (and the -G Xcode projects) have errors (GLUT, objc classes, and perhaps more) as seen in the zipped log attached above.
I don’t know much about CMake (beyond the typical mkdir build && cmake .. && make) and am not intimate will all the platform-specific / project generation (I use the Xcode projects in macOS/iOS and old-school QBS on linux) but I can try things if you need more info.
I’ve got the same errors, it seems like glut lib isn’t downloaded from the apothecary. But it isn’t with the download_libs.sh script either! so it might not be a problem with your cmake code…
