Hello all, meson is a new build system developed by people frustrated by build systems. As usual it pretends it will be better than all others and work fine on most mainstream systems while being easy to read and write. In any case, this new tool depends on python 3 and ninja and due the current state of cmake-utils.eclass and meson itself, we have to create ebuilds not respecting MAKEOPTS, etc while the logic exists in tree. I filed this ticket in order to collect ideas to create a dedicated eclass for meson while sharing some of the utilities found in cmake-utils.eclass. Current users of this eclass would be: * media-libs/gst-transcoder * media-video/pitivi Future expected users : * gstreamer starting with 1.10 (while we expect autotools compatibility at this point still) * some Gnome modules
Why I am the assignee? Anyway, yeah, I agree that we will likely need to create one eclass for this... but I was waiting until more projects are really moving to it and *removing* autotools support (it's not the first time the migration to other build system starts and, later, it's completely aborted and abandoned). And, as soon as major packages are not started to be ported, meson will likely suffer lots of changes (or even be also abandoned because it cannot cover everything needed)
https://github.com/mesonbuild/meson/wiki/Quick%20guide#using-meson-as-a-distro-packager A guide to show how to build using plain meson commands instead of relying on autotools like wrappers In summary we need something like: src_configure() { mkdir build cd build (this two will likely live in another phase) meson --prefix /usr --buildtype=plain .. } src_compile() { ninja -v } src_test() { ninja test } src_install() { DESTDIR=/path/to/staging/root ninja install } The tricky part here is that all the building is done in a external directory (usually a subdir called "build") and, hence, we need to change to that dir as soon as possible and ensure we stay in that directory for all the subsequent phases. We will need to review how packages building with external sources (as usually done with multilib) are handled I guess :/
Also I am unsure about the general "meson --unity" flag: https://github.com/mesonbuild/meson/wiki/Unity%20builds It looks to me something similar to what monolithic-build USE is changing in lyx package compilation :/
It could be worth splitting the ninja-specific stuff out of cmake-utils into its own eclass (this idea has come up a few times now).
Created attachment 469012 [details] meson.eclass All, this is my first crack at a meson eclass. Comments and suggestions are welcome. :-) William
No offense, but William's meson eclass seems mostly pointless. kensington's idea for breaking out the ninja MAKEOPTS code has merit.
I believe the next thing here was to add multilib-minimal wrapping here, and then whatever is needed for cross-compilation stuff.
(In reply to Mike Gilbert from comment #6) > No offense, but William's meson eclass seems mostly pointless. How is it pointless? The idea is to handle the build directory properly and the gentoo-specific settings you would pass to Meson allowing overrides and package specific settings. > kensington's idea for breaking out the ninja MAKEOPTS code has merit. I'm interested in this. The ninja stuff is in cmake-utils.eclass right? (In reply to Mart Raudsepp from comment #7) > I believe the next thing here was to add multilib-minimal wrapping here, and > then whatever is needed for cross-compilation stuff. Is there an example I can look at somewhere to see how to add multilib-minimal wrapping?
meson.eclass is now in the tree.
