QtCreator build with cmake for openframeworks from source in Ubuntu

[Mars-Wave]

https://github.com/Mars-Wave/ubuntuQtOfCmakeBuild/blob/main/README.md

Made this CMakelists.txt to port a project I had in VisualStudio 2019 community in a windows PC to a different computer's linux distribution. I wanted to work in QTCreator, but had tons of issues with the .qbs auto generator. Finally I decided to make the build with cmake relative to the github build from source.

I don't know if it's the smartest approach, but it builds from source. Any suggestions are appreciated, but the cmake is licensed under MIT so feel free to make any changes and inform of your experience.

[Mars-Wave]

ah, also I am new to github contributing, if this is not the place to put this, do let me know, and excuse my inexperience

[artificiel]

hello @Mars-Wave!

here is a good place to discuss build tools. and it's a good moment to brainstorm as many approaches as possible, as it's clearly an area that needs a strong update.

• first quick question: how are addon_config.mk processed, specifically cross-platform treatment of source/libs/compile flags, as well as assets? as I read the CMakeLists you simply "grab all that's there" and let the build ignore the superfluous entries? I'm sure you've looked a the different experiments (CMake, meson, vcpkg), none of which is yet found to be ideal, but in all cases a core problem is how to maintain the compatibility of existing addons. it seems meson is scriptable enough be able to interpret the old addon format into a actionable data structure; maybe CMake can do it? or maybe rely on an external script that would parse and generate a CMakeList for the addon? (that would also handle the include paths). of course if some edge cases are too complicated we can also jettison a bit of the past (especially addons that provide binary libs, which tend to complicate AND quickly go out of date) , but it would be nice to cover >90% of cases).

• second question, your CMakeLists is exhaustive; how would it look if you were to separate the core OF from the "App" (considering project makers would not have to touch the core OF directives, only specify their addons (which at that point would presumably be described by a CMakeLists), and whatever case-specific flags are needed). the idea being that an OF beginner (which is someone encountering the C++ workflow for the first time in a workshop context), should be able to compile an app and see (deal cognitively) with only the strictly required minimum info in their config file.

and note that the goal here is not to race to "make it work" but expand as much as possible the horizon of possibilities so the upcoming design decisions (which includes: what are the expectations we set for OF's distribution process) are as informed as possible.

[Mars-Wave]

For the first question, I will investigate and get back to you, I am fairly new to the project and I only recently started using it heavily, so I am not very aware of it's full capabilities, I can look into it and we can iterate over this :)

For the second question, I do believe there's a point to say about letting the addons into their workflow by compiling them, in QtCreator's way of showing "other locations" in the IDE. If they did want to change that code to add something they find missing, they would always know it's OF's code, and the filenames correspond with the addon... It's a good bait, like "hey, you can change this if you find this code terrible, btw feel free to contribute". Another possibility is making a .a based on the addons asked, but I am unfamiliar with OF's ways as of now, and unless we use some kind of system that tracks if the files are alligned with already built libraries (md5 hashing or maybe what ninja does), I don't know if it's worth it to compile offscreen a .lib or .a for each addon just to keep them offlimits and then link against...
But I do feel that cmakelists is capable of all of this.

Anyhow, do let me know what you think, I do believe you know a lot more than you let me on lol! And I don't mind digging into this issue, granted it took me a long time to do that cmakelists.txt, but I don't mind doing more of it, if it's gonna help others in my same situation. Linux means freedom of choice and less spyware, definitely I feel compelled to destroy hurdles for people who choose it.

And by the way, superb response, I always had a different impression about opensource, but I am seeing it in a very positive light nowadays thanks to the efforts of contributors/supporters like yourself, thank you.

[artificiel]

a challenge with OF is maintaining backwards-compatibility with the custom build system. when it was developed (~2010) it was quite visionary as it is basically a package manager that can assemble projects for various platforms and architectures. now that problem is approachable in many ways, and CMake is probably an ingredient of that, but allowing the integration of an 10-year-old addon like https://github.com/satoruhiga/ofxFastFboReader is a requirement. by default addons have a src/ dir, and PG scans it to incorporate .cpp and .h in the project itself. there are more complicated addons with per-platform flags, assets, etc — you can get info here https://ofxaddons.com/pages/howto#make

some addons do provide compiled .a or .dylib, but that's very cumbersome with the number of OF platforms, and also the fact that they tend to get stale after a few years (OS context changes). but again, now many ways of getting bin packages exists at different levels (OS package manager, Conan/vcpkg/etc) new addons could leverage these if they can have sub-dependencies and focus on their problem of providing an OF-friendly interface to a lib, driver, etc. so we have to find the compromise of best-effort to support the existing.

so the (maybe boring) way of getting up to speed with the current situation is to play with addons and PG and Make (or other IDE projects — unfortunately the OF QtCreator integration broke when QBS went from QScript to Javascript a few years ago) and get a sense of how things are flowing in the current philosophy. also check the CMake, apothecary and meson issues/PR to see what's being tried. what is interesting with meson is that it abstracts what is a "package" (could be a system dependency, .git, a Conan bin or src package, a CMakeFind, etc) which creates a lot of malleability.

[Mars-Wave]

Yes, definitely I will check out the PG flows and PRs people are making, I am sure with a bit of effort we can breathe life into project generation for QtCreator again. I definitely feel it is worth it since QtCreator aligns more with the general philosophy of OF since everything kind of works out of the box (clangd, clang-format, project views...) as opposed to spending hours upon hours configuring VScode, which is my other non-Windows "IDE" where I am comfortable devving. Also, QtCreator with make might be a lot more backwards compatible... Even to get VSCommunity + OF working in my windows PC I couldn't find exactly the one that PG needed, and ended up messing around with .vcxproj and .sln files to make the paths work...
Cheers!