Meson build system proof-of-concept #8137
Conversation
|
interesting! NB: zero experience with meson here
|
|
NB: tried running PG over you test repo and a copy of your ofxGamePad fork and got here: (and yes, the point of something like meson is to not rely on ofxAddon — write a meson.build and get the dependency! but just to be sure nothing here is to be construed as negative — it is very important to explore/discuss build systems and what facilitates usage; i'm really looking at it with the question of "how could OF transparently migrate" while maintaining a core principle which is "garanteed results on the supported platforms in harsh conditions" (think workshop with disparate machines or admin restrictions), where as long as you have a C++17 toolchain, you can download an OF.gzip in a writable directory and get compiling (NB: on linux you might have to get distro-sanctionned packages, which presumes sudo-rights)). thinking a bit more about PG's role: meson-ification in addons' cases currently means: having a local copy of an addon, start with addon_config.mk and from there gathering source and accumulating flags and libs, perhaps platform-conditional. the problem is the same with all build tools. so i guess a question is: what is the ideal "addon descriptor" (really: a package description) that could translate to different build systems? ideally we'd support CMake, meson, etc, but don't expect addon writers to know about them all — so perhaps think of a kind of universal addon description (what addon_config.mk ends up being, even for non-Make projects such as Xcode). |
|
Hey, Thanks for your feedback !
No they are not needed, it's like
There's nothing magical with So now, if I go back to the meson alternative:
Can you tell me what headers in the
Meson is really fitting in these situations with the approach with subprojects and wraps: where the needed dependencies can simply be downloaded automatically by meson instead of relying on what the distro provides. When you run this snippet git clone https://github.com/AdelKS/interactive-physarum.git --depth=1
cd interactive-physarum
meson setup buildyou will see that subprojects get automatically and recursively pulled by meson: openFrameworks, kissfft, libtess2 . The projects that can be downloaded automatically by meson are listed here (called wrapdb), and allegedly every So in your case for example let's say |
indeed source (.h/.cpp) in
hmm i am not an apothecary expert so i'm not sure how to guide you correctly there (probably look into what kind of insight is implemented in apothecary around the platform?). as a reference here are the macOS "builtin" libraries that are shipped from apothecary (either provided in the bin releases, or via the script download_libs), so they can perhaps be considered "always required"? (because another design point is not to rely on homebrew on macOS, which is something that can be re-discussed, but again it's thinking about hostile workshop environments where you have 30 minutes to setup 16 machines for people unfamiliar with the command line. on linux it's more lax and But we can distinguish 2 distinct clusters of issues — the platform-specific treatment of providing libraries (which can get hairy when dealing with iOS or rPI), and the method of packaging/discovering/acquiring 3rd-party functionalities as supported by the ofxaddon ecosystem and Project Generator (which also solves producing projects files for a bunch of IDEs). NB: for sure, a problem |
AdelKS
force-pushed
the
meson
branch
2 times, most recently
from
f321fbd to
12b06a5
Compare
|
Somehow I could build without these Some changes:
Don't think it will make my example compile for you, but it should go a little bit further. That's how I believe we can handle everything using meson. |
|
(the packages you mention not needing are not used by "empty" projects but will be needed on a case-by-case (for instance fmod for audio stuff). but getting further! for fun, did
|
I probably did not make it clear, but for now I am focusing on making the "core" library be compilable, i.e. the source files in the
As you can see here, it's a Let's see where the next blocker is. |
|
ok, still stuck at i don't think that makes sense on macOS anyhow? (i'm not sure how to find what triggers the |
|
I think that’s a Linux only library and can be ignored.
Love seeing these explorations for build systems.
Was trying out Conan and vcpkg today.
|
I moved the You probably didn't get my latest changes, In your downstream local clone of
Would love to hear your feedback on them, never tried those either. |
got it! next up: note that (as far as i know, perhaps that changed recently) OF uses a customized FreeImage fork: https://github.com/danoli3/FreeImage |
Thanks! I couldn't put it in a wrap before because the original project doesn't use Next issue please 🗡️ |
A wrap file basically tells meson how to download a subproject and what
dependency it fullfills. So when we do dependency('foo') in meson.build
and foo is not available in the host system, it will automatically download
it and configure it so it uses as a "subproject"
More information here https://mesonbuild.com/Wrap-dependency-system-manual.html
e.g. Archlinux doesn't bundle it
Ubuntu / Debian have it called 'glut'
installed using the command meson wrap install <lib-name>
|
Quite a few more lines added to handle disabling a cmake define
Unfortunately Meson doesn't offer an easy way to do something like this
dependency('uriparser', default_options: {'URIPARSER_BUILD_DOCS': false})
where the second argument is automatically given to cmake
Just like 'uriparser' we need to disable an option in the cmake subproject to not pull extra dependencies
Not useful for the core library, but will be useful for ofxAssimp
|
@ofTheo a feature of Conan (that as far as i understand vcpkg does not support) is:
which means the equivalent of the apothecary could be published as conan packages, and prebuilt as needed. officially supported platforms could be provided and pinned-to with version numbers, andthey would be assembled for "static" distribution on supported platforms, gathering the libs from conan and tarballing them for the equivalent of the current binary "semver" releases. hosting a conan upstream is also possible, perhaps a way to envision addons as conan packages. one thing for sure though: a critical aspect is to think how addons themselves can resolve dependencies, to solve the lib-wrapper addon author problem of "should i provide source, or bin-per-platform, or git submodules, or a shell script, or README instructions to install manually". CMake seems to be establishing itself as a kind of universal dependency format (what i was mentionning above as a "generic" addon description file). if Project Manager can read in addon_config.mk and spit out the corresponding CMakeLists.txt (perhaps localized to the PG user's platform, or in a generic platform-switched manner) it would pave the way to a transition. old addons would be supported via PG, and fresh addons would also sport a CMakeLists and be useable without PG. |
|
Fixed. Next ! You can add me in Discord as |
|
OK but now |
|
How is this issue currently handled ? It looks like |
|
Okay I just tried something, please try again |
|
In Xcode those files are compiled as objective-c / c++
I think we might have a rule in the makefiles that does the same.
|
|
OK making progress, now to the linker! (just so you don't feel left hanging as this thread has a "chat" feel — i must now leave and will not get back to this space before monday noon EST) |
|
I added some dependencies, that should fix these errors. Let's see on Monday 🗡️ |
AdelKS
force-pushed
the
meson
branch
2 times, most recently
from
f63cfb7 to
75079bc
Compare
|
same linking error (but it's task 6/40 instead of 12/37, so something changed) link_error.txt |
|
Okay, I added the |
|
there were some missing commas near: fixed that but then stuck on: tried forcing clang++ with |
|
Ah yeah, I added |
|
more objc++ compile fun: it's about weak references which are related to retain-release and there is a note to enabling ARC Automatic Reference Counting — it means adding |
|
I added it in the line |
AdelKS
force-pushed
the
meson
branch
2 times, most recently
from
6226351 to
aeabf3e
Compare
|
Loving to see the progress on all of this. Apothecary is a Herculean effort at this point and it's so refreshing on linux to run install_dependencies.sh and take care of 90% of the library needs of OF.
Ah interesting @artificiel - I did try requesting static packages with Conan and they didn't exist for macOS but nice that they can be shared publicly if we did build them. |
|
still had some errors and decided to actually look into 🍾 attached is a modified OF build file (was missing some more frameworks and also .m support for the single pure objc file we have...) it's probably not perfect but it got past the problems meson.build.zip now, unfortunately no compute shaders on macOS hah so your demo app can't run sorry about that. also not sure but it does not seem to find the some questions / refinements to further develop this proof of concept:
|
Treat files as Objective-C++ instead of C++ because some included macos headers are Objective-C++ Objective-C++ apparently is a superset of C++ so we should be all good Co-authored-by: Alexandre Burton <[email protected]> Co-authored-by: Adel KARA SLIMANE <[email protected]>
Not strictly required, can be tuned e.g. for each build folder
So it can be cached with MESON_PACKAGE_CACHE_DIR
Awesome ! I am happy you found it easy to hack. So in the end you only needed
Did not know that it doesn't handle OpenGL compute shaders, but I suppose it can still cross-compile those GLSL shaders to Metal Shading Language. I was reading recently about how Qt handles multi-platform, with QSB and QShader.
It probably comes from differences on how OF handles loading relative paths in different platforms.
You can check the ofxGamepad project which depends directly on OF. But it's basically the same approach:
I just pulled that part from my own projects, this block can be entirely removed, except maybe default_options : [
'cpp_std=c++20',
'buildtype=release',
'optimization=3',
'default_library=shared',
# 'prefer_static=true',
'b_ndebug=if-release',
'c_args=-pipe',
'cpp_args=-pipe',
# 'warning_level=3'
]
The rationale still applies to those unfortunately (how to quickly track changes?). You can do this with some caveats. Now let's question this approach:
Two possibilities:
An interesting extra information about shipping prebuilt libraries directly with wraps |
|
ok thanks for all this! it helps and is great to see an OF binary out of meson/ninja. obviously as @ofTheo mentions the whole OF package/addon/PG system needs a refresh, and it's difficult to define the correct solution as while the philosophy of things can evolve, they still have to work unilaterally on day 1, be backwards-compatible, stay simple for beginners to get code compiled, ultimately be an improvement, and with less maintaining. then once that's decided there is a CHUNK of work to be done... which must not be underestimated as in that kind of refactoring, 95% completion is a failure, and it's not really something that can be done progressively. so let's keep this issue floating for quick reference as the various tendrils of thought weave and tighten around the subject matter. |
|
Great initiative! and some related discussion |
Hey,
I am well aware of #7524 but thought that maybe you'd like to see alternative build systems, in this case meson
Why a build system
Having a proper build system has the following advantages:
openFrameworkspackageable by distrosPotential disadvantages:
As I understand it,
openFrameworksdid in the end develop its homemade build system components (projectGeneratorandApothecary?) and a way to embed Add-ons, either in-tree or out of tree. So it looks like a "build lock-in" always happens when a project grows big enough.Why
mesonUnfortunately I have no experience whatsoever with
cmakeso I cannot say anything out of my own experience, except that I decided to learn meson instead because it's way more readable and python-like. Otherwise:How to define a meson project
meson.buildfile at the root of the project (required)meson.buildfiles in subfolders (optional)meson.buildfileThe usual process of making meson projects: fill the
meson.buildfile at the root of the project.sources = files(...)inc = include_directories(...)/usr/include/openFrameworks/../foo.hwhen installed usingmeson installwithin a build folderdeps = [ dependency('foo'), dependency('bar), ...]pkgconfigfile using the pkgconfig moduleHow to compile a meson project
This PR: proof-of-concept on the usage of
mesonbuild systemThis PR, on top of adding initial
mesonbuild system support toopenFrameworks, comes with amesonified fork of a downstream "user" project to demo how it can be used. The project I chose is interactive-physarum from @Bleuje.Using a Linux distro with all the required
openFrameworksdependencies installed, exceptlibtess2andkissfft,mesonwill complain if some are missing. You can clone, pull some deps, compile and run the app without having openframeworks installed nor downloaded anywhere in the systemThe above
mesonified itopenFrameworkscan potentially handle (out-of-tree) Add-onsopenFrameworkshasn't been installed on the distro machine.libtess2andkissfftwhich have been "meson wrapped" as subprojectscmakeormeson.meson.buildfor such projectslibtess2it wasn't the case, and I wrote themeson.buildfile for it myself (it's insubprojects/projectfiles/libtess2/meson.build)Limitations of this POC PR
meson.buildcode is far from being final#definesand conditionally compiling some of the sources given the target needs to be done