GNOME Bugzilla – Bug 789316
Add Meson support in cerbero
Last modified: 2018-05-02 17:44:33 UTC
It invokes ./install_meson.py command that seems to not exist anymore. I think it should be using the standard setup.py instead, but that's tricky because cerbero is python2 and meson is python3, so the PYTHONPATH must be modified, unless I'm mistaken?
The following fixes have been pushed:
Created attachment 362037 [details] [review] Add call_env arg to shell.call()
Created attachment 362038 [details] [review] Config: Add modify_env_for_python3 helper When cerbero needs to call python3 commands, PYTHONPATH must be modified in the environ.
Created attachment 362039 [details] [review] Fix meson recipe
Created attachment 362043 [details] [review] Update meson version to 0.43.0
It seems like the only thing that needs meson in cerbero is gst-transcoder? I think we should remove this recipe and install it as a system dependency in bootstrap instead. Every distro ships Python3 and that's the only dependency of Meson, so it's not going to be a significant burden. If you want to add meson support to recipes within Cerbero, you will really want to rebase the patches in https://github.com/centricular/cerbero. A lot of them are about adding MSVC support, but the commits are discrete and you should be able to pull in only the Meson stuff. I haven't gotten to it yet because there was a lot of churn during 1.12 especially around the -static recipes.
Created attachment 362051 [details] [review] Drop meson recipe and add it as part of bootstrap
This patch is missing windows/ios bootstrap, I have no idea how it they work, and have no way to test. Also missing the package name for pip3 on rh/fedora/etc. I tested on Ubuntu 16.04.
Review of attachment 362051 [details] [review]: ::: cerbero/bootstrap/linux.py @@ +52,3 @@ + + if meson_needed: + shell.call('pip3 install meson') pip3 should only be used on older distros and on Windows/macOS. I think this should also be `pip3 install --user` on Linux because people will not appreciate Cerbero installing anything outside of $HOME. @@ +71,3 @@ 'libxtst-dev', 'libxrandr-dev', 'libglu1-mesa-dev', + 'libegl1-mesa-dev', 'git', 'subversion', 'xutils-dev', + 'python3-pip'] I think we should use the distro-provided meson for recent distros (such as debian testing and unstable, fedora 25/26, ubuntu artful, etc).
Created attachment 362053 [details] [review] Drop meson recipe and add it as part of bootstrap
I'm too lazy to check distro-by-distro which version of meson they have, so this patch just always install meson and python3-pip and if "meson --version" says it's too old it will pip install it.
(In reply to Xavier Claessens from comment #11) > I'm too lazy to check distro-by-distro which version of meson they have, so > this patch just always install meson and python3-pip and if "meson > --version" says it's too old it will pip install it. This is probably the better solution since it's future-proof too. It also means that we will use whatever meson the user has in their PATH. Just one more thing: using pip3 install --user means we need to ensure that ~/.local/bin is in our PATH. Does that require changes to our config?
Created attachment 362062 [details] [review] Drop meson recipe and add it as part of bootstrap
I don't know if all distro has .local/bin in PATH by default. I don't know what needs to be added in PATH for windows and ios though.
Created attachment 362215 [details] [review] Meson: Drop meson recipe and add it as part of bootstrap
Created attachment 362216 [details] [review] Meson: extract ModifyEnvBase class out of MakefilesBase This is the common part between Makefile based build and the future Meson based build.
Created attachment 362217 [details] [review] Meson: Add BuildType.Meson to compile recipes
Created attachment 362218 [details] [review] Meson: Port gst-transcoder recipe
Here is a first step at making Meson recipes first class citizen. I chosed to port only gst-transcoder for now because it is the only one that is already being built using meson. I updated Windows instructions in README to install Meson and python3. I tested those steps on a fresh install of Win10 in a VM. On my Ubuntu 16.04, gst-transcoder fail to build with that error: Error in gtkdoc helper script: 'gtkdoc-scangobj' failed with status 1 ld: unrecognized option '-Wl,-rpath,/home/xclaesse/programmation/cerbero/build/sources/linux_x86_64/gst-transcoder-1.9/cerbero-build-dir/' ld: use the --help option for usage information Linking of scanner failed: I get the exact same error when trying to build gstreamer-1.0 recipe ported to Meson. Any Idea?
Review of attachment 362218 [details] [review]: Marking this commit as needs-work because it fails to build for me.
Created attachment 362353 [details] [review] Meson: Drop meson recipe and add it as part of bootstrap
Created attachment 362354 [details] [review] Meson: Drop meson recipe and add it as part of bootstrap
Created attachment 362355 [details] [review] Meson: extract ModifyEnvBase class out of MakefilesBase This is the common part between Makefile based build and the future Meson based build.
Created attachment 362356 [details] [review] Meson: Add BuildType.Meson to compile recipes Based on code from Nirbheek Chauhan <nirbheek@centricular.com>
Created attachment 362357 [details] [review] Meson: Add exe_wrapper support while cross-compiling This allows us to specify the wrapper that Meson should use to run executables while cross-compiling. Currently just has cross-win* support, but more can be added later including qemu for arm targets, etc.
Created attachment 362369 [details] [review] Meson: Add BuildType.Meson to compile recipes Based on code from Nirbheek Chauhan <nirbheek@centricular.com>
(In reply to Xavier Claessens from comment #19) > Here is a first step at making Meson recipes first class citizen. I chosed > to port only gst-transcoder for now because it is the only one that is > already being built using meson. > > I updated Windows instructions in README to install Meson and python3. I > tested those steps on a fresh install of Win10 in a VM. > > On my Ubuntu 16.04, gst-transcoder fail to build with that error: > > Error in gtkdoc helper script: > 'gtkdoc-scangobj' failed with status 1 > ld: unrecognized option > '-Wl,-rpath,/home/xclaesse/programmation/cerbero/build/sources/linux_x86_64/ > gst-transcoder-1.9/cerbero-build-dir/' > ld: use the --help option for usage information > Linking of scanner failed: > > > I get the exact same error when trying to build gstreamer-1.0 recipe ported > to Meson. Any Idea? How about just disabling document generation by adding the below? + def configure(self): + self.meson_configure['disable_doc'] = 'true' + super(recipe.Recipe, self).configure()
That works of course, but I would like to get it working rather than hiding the bug. But I'm out of ideas to fix this one...
Comment on attachment 362218 [details] [review] Meson: Port gst-transcoder recipe This recipe builds fine once this meson pull request gets merged: https://github.com/mesonbuild/meson/issues/2540
Created attachment 362422 [details] [review] Meson: Add BuildType.Meson to compile recipes Based on code from Nirbheek Chauhan <nirbheek@centricular.com>
Created attachment 362555 [details] [review] Meson: Drop meson recipe and add it as part of bootstrap
Created attachment 362556 [details] [review] Meson: extract ModifyEnvBase class out of MakefilesBase This is the common part between Makefile based build and the future Meson based build.
Created attachment 362557 [details] [review] Meson: Add BuildType.Meson to compile recipes Based on code from Nirbheek Chauhan <nirbheek@centricular.com>
Created attachment 362558 [details] [review] Meson: Add exe_wrapper support while cross-compiling This allows us to specify the wrapper that Meson should use to run executables while cross-compiling. Currently just has cross-win* support, but more can be added later including qemu for arm targets, etc.
Created attachment 362559 [details] [review] Meson: Add 'meson' variant disabled by default When enabling this variant, recipes supporting it will be built using Meson instead of Autotools.
Created attachment 362560 [details] [review] Meson: Port gst-transcoder recipe
Created attachment 362561 [details] [review] Meson: Port GStreamer Core recipe
Created attachment 362562 [details] [review] Meson: Port GStreamer Base recipe
I think this is a really good start, you can add `variants = ['meson']` into your ~/.cerbero/cerbero.cbc to make gst core/base build with meson. I think we should start setuping CI that uses that variant to ensure GStreamer always builds fine using meson. Of course more recipes should be ported.
(In reply to Xavier Claessens from comment #39) > I think this is a really good start, you can add `variants = ['meson']` into > your ~/.cerbero/cerbero.cbc to make gst core/base build with meson. I think > we should start setuping CI that uses that variant to ensure GStreamer > always builds fine using meson. Note, we already have meson builds on ci.gstreamer.net, just not using cerbero atm. I overall agree this is a nice intermediate step.
(In reply to Nicolas Dufresne (stormer) from comment #40) > Note, we already have meson builds on ci.gstreamer.net, just not using > cerbero atm. I overall agree this is a nice intermediate step. But not for cross builds, right?
(In reply to Xavier Claessens from comment #41) > (In reply to Nicolas Dufresne (stormer) from comment #40) > > Note, we already have meson builds on ci.gstreamer.net, just not using > > cerbero atm. I overall agree this is a nice intermediate step. > > But not for cross builds, right? No, only native builds right now, so it would indeed be a nice intermediary addition fmpov.
Created attachment 362693 [details] [review] Meson: Drop meson recipe and add it as part of bootstrap
Created attachment 362694 [details] [review] Meson: extract ModifyEnvBase class out of MakefilesBase This is the common part between Makefile based build and the future Meson based build.
Created attachment 362695 [details] [review] Meson: Add BuildType.Meson to compile recipes Based on code from Nirbheek Chauhan <nirbheek@centricular.com>
Created attachment 362696 [details] [review] Meson: Add exe_wrapper support while cross-compiling This allows us to specify the wrapper that Meson should use to run executables while cross-compiling. Currently just has cross-win* support, but more can be added later including qemu for arm targets, etc. Based on code from: Nirbheek Chauhan <nirbheek@centricular.com> Justin Kim <justin.kim@collabora.com>,
Created attachment 362697 [details] [review] Meson: Add 'meson' variant disabled by default When enabling this variant, recipes supporting it will be built using Meson instead of Autotools.
Created attachment 362698 [details] [review] Meson: Port gst-transcoder recipe
Created attachment 362699 [details] [review] Meson: Port gstreamer-1.0 recipe
Created attachment 362700 [details] [review] Meson: Port gst-plugins-base-1.0 recipe
I can now cross build for android at least gstreamer core and base.
Created attachment 362701 [details] [review] Meson: Add BuildType.Meson to compile recipes Based on code from Nirbheek Chauhan <nirbheek@centricular.com>
Created attachment 362704 [details] [review] Meson: Add BuildType.Meson to compile recipes Based on code from Nirbheek Chauhan <nirbheek@centricular.com>
The 2 patches needed in Meson to get this working got merged now.
Ideally they'd also get into a release so we don't have to use a random git snapshot of Meson :)
There is a release every month, 0.44.0 should be rsn.
meson 0.44.0 is coming today. :)
Created attachment 365499 [details] [review] Meson: Drop meson recipe and add it as part of bootstrap
Created attachment 365500 [details] [review] Meson: extract ModifyEnvBase class out of MakefilesBase This is the common part between Makefile based build and the future Meson based build.
Created attachment 365501 [details] [review] Meson: Add BuildType.Meson to compile recipes Based on code from Nirbheek Chauhan <nirbheek@centricular.com>
Created attachment 365502 [details] [review] Meson: Add exe_wrapper support while cross-compiling This allows us to specify the wrapper that Meson should use to run executables while cross-compiling. Currently just has cross-win* support, but more can be added later including qemu for arm targets, etc. Based on code from: Nirbheek Chauhan <nirbheek@centricular.com> Justin Kim <justin.kim@collabora.com>,
Created attachment 365503 [details] [review] Meson: Port gst-transcoder recipe
Rebased on master, dropped patches that port recipes to meson because that's probably premature. Only kept gst-transcoder because that one is already meson-only.
Review of attachment 365499 [details] [review]: ::: README @@ +37,3 @@ ------- The initial setup on Windows is a little bit longer, but only a few programs are required. + * Python2.7 AND Python3.6: https://www.python.org/downloads/ This should be merged after porting to Python 3 IMHO. Requiring two versions of Python is just silly ::: cerbero/bootstrap/linux.py @@ +52,3 @@ + + if meson_needed: + shell.call('pip3 install --user meson') How would meson installed on non-Unix? Seems to be missing Why do we install via PIP instead of having a recipe? Updating with PIP or ensuring that at least a specific version is used seems less than ideal
Review of attachment 365501 [details] [review]: ::: cerbero/build/build.py @@ +408,3 @@ + ModifyEnvBase.__init__(self) + + self.meson_dir = os.path.join(self.build_dir, "cerbero-build-dir") Make this a bit shorter please, think of poor Windows with its limited capability of handling long paths :) @@ +413,3 @@ + if self.config.cross_compiling(): + self.new_env['CC'] = None + self.new_env['CXX'] = None Why? Maybe the user wanted to build with clang instead of gcc? @@ +459,3 @@ + # Take CC and CXX from _old_env because we modified env to make them be + # the native toolchain. If the variable is not set, we assume we want + # MSVC Why? on Windows this might make sense, but not in general
Comment on attachment 365502 [details] [review] Meson: Add exe_wrapper support while cross-compiling This requires the bootstrap for the cross-win* targets to install wine then
(In reply to Sebastian Dröge (slomo) from comment #64) > + * Python2.7 AND Python3.6: https://www.python.org/downloads/ > > This should be merged after porting to Python 3 IMHO. Requiring two versions > of Python is just silly I agree but it seems we are not there yet, sadly. I don't think we should block on py3 porting, do we? > ::: cerbero/bootstrap/linux.py > @@ +52,3 @@ > + > + if meson_needed: > + shell.call('pip3 install --user meson') > > How would meson installed on non-Unix? Seems to be missing Up to the user to pip install it, like said in README. I guess we could add similar code in other OS bootstrap for convenience. > Why do we install via PIP instead of having a recipe? Updating with PIP or > ensuring that at least a specific version is used seems less than ideal It is actually complicated to have it as recipe because we mix python2 and python3 here and we can only set PYTHON_PATH to one of them. It can be work around (my initial patches did that) but nirbeek said we should just consider meson comes from your system. (In reply to Sebastian Dröge (slomo) from comment #65) > + self.meson_dir = os.path.join(self.build_dir, "cerbero-build-dir") > Make this a bit shorter please, think of poor Windows with its limited > capability of handling long paths :) Maybe just "builddir" ? We should make sure to not be too generic otherwise it would clash with a folder that projects has in git. Like glib has a "build" folder. > @@ +413,3 @@ > + if self.config.cross_compiling(): > + self.new_env['CC'] = None > + self.new_env['CXX'] = None > > Why? Maybe the user wanted to build with clang instead of gcc? Yeah, that's a bit a quick hack... The problem is with meson you must have the native compiler in env and set the target compiler in meson-cross-file.txt. Unfortunately cerbero always set the target compiler in env. See how in write_meson_cross_file() it takes the compiler from self._old_env to write it in the file. Ideally in config.py we should load both native and target envs, then have a way to switch between them depending on the type of recipe you're building. That's much more work and I'm not exactly sure how to do that. So yes, that's an ugly hack, but it makes stuff work. Do you think that's merge blocker? > @@ +459,3 @@ > + # Take CC and CXX from _old_env because we modified env to make > them be > + # the native toolchain. If the variable is not set, we assume we > want > + # MSVC > > Why? on Windows this might make sense, but not in general That's from nirbeek branch, it defaults to MSVC. CMake default to "gcc" which is equaly wrong I guess... We should not even need a default there, in practice you should always have a compiler set in your env, no? (In reply to Sebastian Dröge (slomo) from comment #66) > This requires the bootstrap for the cross-win* targets to install wine then Do we even ever run target platform binaries? That wasn't supported before, not sure we need this. That's from nirbeek. IMO wine is a big and unreliable dependency to have. I guess we should test if cross build still works without that.
(In reply to Xavier Claessens from comment #67) > (In reply to Sebastian Dröge (slomo) from comment #64) > > + * Python2.7 AND Python3.6: https://www.python.org/downloads/ > > > > This should be merged after porting to Python 3 IMHO. Requiring two versions > > of Python is just silly > > I agree but it seems we are not there yet, sadly. I don't think we should > block on py3 porting, do we? I'm fine with requiring both for a short while until the py3 port is finished (work is being done on that currently AFIAU), as long as you can confirm that there are no weird problems with using both versions in cerbero :)
(In reply to Xavier Claessens from comment #67) > > Why do we install via PIP instead of having a recipe? Updating with PIP or > > ensuring that at least a specific version is used seems less than ideal > > It is actually complicated to have it as recipe because we mix python2 and > python3 here and we can only set PYTHON_PATH to one of them. It can be work > around (my initial patches did that) but nirbeek said we should just > consider meson comes from your system. I'm fine with that until the py3 port is in, but then please add a recipe for that. > (In reply to Sebastian Dröge (slomo) from comment #65) > > + self.meson_dir = os.path.join(self.build_dir, "cerbero-build-dir") > > Make this a bit shorter please, think of poor Windows with its limited > > capability of handling long paths :) > > Maybe just "builddir" ? We should make sure to not be too generic otherwise > it would clash with a folder that projects has in git. Like glib has a > "build" folder. Maybe "build", and if existing already "build_", "build__", etc? "builddir" could equally conflict > So yes, that's an ugly hack, but it makes stuff work. Do you think that's > merge blocker? No, but open another Bugzilla bug about that so it's not forgotten. That should be fixed sooner or later, it's ugly :) It also seems weird that meson needs the host compiler in the environment. I thought meson hates environment variables for everything... > > @@ +459,3 @@ > > + # Take CC and CXX from _old_env because we modified env to make > > them be > > + # the native toolchain. If the variable is not set, we assume we > > want > > + # MSVC > > > > Why? on Windows this might make sense, but not in general > > That's from nirbeek branch, it defaults to MSVC. CMake default to "gcc" > which is equaly wrong I guess... We should not even need a default there, in > practice you should always have a compiler set in your env, no? Yes, or cerbero should make sure that this is the case. Is this part needed, and if so, for what exactly? > (In reply to Sebastian Dröge (slomo) from comment #66) > > This requires the bootstrap for the cross-win* targets to install wine then > > Do we even ever run target platform binaries? That wasn't supported before, > not sure we need this. That's from nirbeek. IMO wine is a big and unreliable > dependency to have. I guess we should test if cross build still works > without that. AFAIU meson might do that. autotools does not.
When cerbero is running with python3 it is really easy to build meson inside cerbero instead of requiring to pip install it. So let's wait for those patches to get merged first.
Created attachment 365801 [details] [review] Meson: Bump version to 0.44.0 Now that cerbero is running with python3, PYTHONPATH is refering to python3 path. This makes the meson built inside cerbero usable with our build env.
Created attachment 365802 [details] [review] Meson: extract ModifyEnvBase class out of MakefilesBase This is the common part between Makefile based build and the future Meson based build.
Created attachment 365803 [details] [review] Meson: Add BuildType.Meson to compile recipes Based on code from Nirbheek Chauhan <nirbheek@centricular.com>
Created attachment 365804 [details] [review] Meson: Port gst-transcoder recipe
(In reply to Sebastian Dröge (slomo) from comment #69) > (In reply to Xavier Claessens from comment #67) > > > > Why do we install via PIP instead of having a recipe? Updating with PIP or > > > ensuring that at least a specific version is used seems less than ideal > > > > It is actually complicated to have it as recipe because we mix python2 and > > python3 here and we can only set PYTHON_PATH to one of them. It can be work > > around (my initial patches did that) but nirbeek said we should just > > consider meson comes from your system. > > I'm fine with that until the py3 port is in, but then please add a recipe > for that. Rebased my patchset on top of my python3 branch (bug #733067). Meson is now built inside cerbero. No need to pip install it anymore. > > (In reply to Sebastian Dröge (slomo) from comment #65) > > > + self.meson_dir = os.path.join(self.build_dir, "cerbero-build-dir") > > > Make this a bit shorter please, think of poor Windows with its limited > > > capability of handling long paths :) > > > > Maybe just "builddir" ? We should make sure to not be too generic otherwise > > it would clash with a folder that projects has in git. Like glib has a > > "build" folder. > > Maybe "build", and if existing already "build_", "build__", etc? "builddir" > could equally conflict It cannot just add _ until it finds a dir that doesn't exists because if we run again the compile step it must reuse the same dir that previous run. I opted for "_builddir" which should be unique, short and sort first when you browse the folder. > > So yes, that's an ugly hack, but it makes stuff work. Do you think that's > > merge blocker? > > No, but open another Bugzilla bug about that so it's not forgotten. That > should be fixed sooner or later, it's ugly :) Opened bug #791670 and linked to it in a comment. > > That's from nirbeek branch, it defaults to MSVC. CMake default to "gcc" > > which is equaly wrong I guess... We should not even need a default there, in > > practice you should always have a compiler set in your env, no? > > Yes, or cerbero should make sure that this is the case. Is this part needed, > and if so, for what exactly? I removed the default value. > > (In reply to Sebastian Dröge (slomo) from comment #66) > > > This requires the bootstrap for the cross-win* targets to install wine then > > > > Do we even ever run target platform binaries? That wasn't supported before, > > not sure we need this. That's from nirbeek. IMO wine is a big and unreliable > > dependency to have. I guess we should test if cross build still works > > without that. > > AFAIU meson might do that. autotools does not. Dropped that patch, it doesn't seems to be needed, for now at least.
Created attachment 365813 [details] [review] Meson: Bump version to 0.44.0 Now that cerbero is running with python3, PYTHONPATH is refering to python3 path. This makes the meson built inside cerbero usable with our build env.
*** Bug 768028 has been marked as a duplicate of this bug. ***
Created attachment 370221 [details] [review] Fix the meson recipe and bump version to 0.45.1 Now that cerbero is running with python3, PYTHONPATH is refering to python3 path. This makes the meson built inside cerbero usable with our build env.
Created attachment 370222 [details] [review] Meson: extract ModifyEnvBase class out of MakefilesBase This is the common part between Makefile based build and the future Meson based build.
Created attachment 370223 [details] [review] Meson: Add BuildType.Meson to compile recipes Based on code from Nirbheek Chauhan <nirbheek@centricular.com>
Created attachment 370224 [details] [review] Meson: Port gst-transcoder recipe
Created attachment 370243 [details] [review] Meson: Add BuildType.Meson to compile recipes Based on code from Nirbheek Chauhan <nirbheek@centricular.com>
Review of attachment 370243 [details] [review]: ::: cerbero/build/build.py @@ +516,3 @@ + + for (key, value) in self.meson_options.items(): + meson_cmd += ' -D%s=%s' % (key, str(value)) I wonder if we shouldn't always write a meson file if any of those values are set? In case one wants to override the CC, etc even when not cross-compiling really. For example, to use clang instead of gcc, or to use icc.
You can set CC and CXX in your env for that. Meson takes the native toolchain from your env, and the cross toolchain from that file.
Created attachment 370591 [details] [review] Fix the meson recipe and bump version to 0.45.1 Now that cerbero is running with python3, PYTHONPATH is refering to python3 path. This makes the meson built inside cerbero usable with our build env.
Created attachment 370592 [details] [review] Meson: extract ModifyEnvBase class out of MakefilesBase This is the common part between Makefile based build and the future Meson based build.
Created attachment 370594 [details] [review] Meson: Add BuildType.Meson to compile recipes Based on code from Nirbheek Chauhan <nirbheek@centricular.com>
Created attachment 370596 [details] [review] Meson: Port gst-transcoder recipe
Created attachment 370597 [details] [review] Meson: Let recipes define cross compilation properties With autoconf we used to define variables like glib_cv_stack_grows in the environ, but with meson those variables needs to be defined inside the cross-file we generate. For example GLib will be using those properties: https://bugzilla.gnome.org/show_bug.cgi?id=794898.
Review of attachment 370594 [details] [review]: ::: cerbero/build/build.py @@ +425,3 @@ + # Find Meson + if not self.meson_sh: + make_install = None There's a corner case when building on Mac. If meson is installed by Homebrew on Mac OS X, it should be 'meson.py' because 'meson' is a batch shell.
We don't use system meson, cerbero install it's own, so I think it should work on macos too. Did you try?
(In reply to Xavier Claessens from comment #91) > We don't use system meson, cerbero install it's own, so I think it should > work on macos too. Did you try? Ah, yes. I forgot to run `bootstrap` while checking.
Review of attachment 370591 [details] [review]: lgtm
Review of attachment 370592 [details] [review]: lgtm
Review of attachment 370594 [details] [review]: ::: cerbero/build/build.py @@ +399,3 @@ + --default-library=%(default-library)s --buildtype=%(buildtype)s \ + --backend=%(backend)s ..' + default_library = 'shared' Do we want to change this? This made sense when we had separate recipes for static and shared, and this value would be overriden in the static recipes. @@ +425,3 @@ + # Find Meson + if not self.meson_sh: + self.meson_sh = self.config.python_exe + ' ' + shell.which('meson') I originally used shell.which('meson') here because meson.py was installed into the system prefix. But since it's in the build tools prefix, we know exactly where it is. We should use that path directly. This also means we don't need find_build_tools(), and we can hard-code paths to both meson and ninja in the class variables.
Review of attachment 370596 [details] [review]: looks good, once the other patches in this bug are merged.
Review of attachment 370597 [details] [review]: Do we still need this since glib doesn't seem to need any special cross properties now?
(In reply to Nirbheek Chauhan from comment #95) > Review of attachment 370594 [details] [review] [review]: > > ::: cerbero/build/build.py > @@ +399,3 @@ > + --default-library=%(default-library)s --buildtype=%(buildtype)s > \ > + --backend=%(backend)s ..' > + default_library = 'shared' > > Do we want to change this? This made sense when we had separate recipes for > static and shared, and this value would be overriden in the static recipes. Note we still have glib-networking-static but that's going away when we update to latest glib, I made the patch upstream to build static gio modules. I guess we should set default_library='both' as soon as meson 0.46 gets released. But we cannot always build static, for example glib cannot do static for windows atm. So I think we still need to be able to override default_library from recipes. > @@ +425,3 @@ > + # Find Meson > + if not self.meson_sh: > + self.meson_sh = self.config.python_exe + ' ' + > shell.which('meson') > > I originally used shell.which('meson') here because meson.py was installed > into the system prefix. But since it's in the build tools prefix, we know > exactly where it is. We should use that path directly. > > This also means we don't need find_build_tools(), and we can hard-code paths > to both meson and ninja in the class variables. Good point, I'm happy to be able to remove that hack, I'll update patch in a bit.
(In reply to Nirbheek Chauhan from comment #97) > Review of attachment 370597 [details] [review] [review]: > > Do we still need this since glib doesn't seem to need any special cross > properties now? Yes we need this for glib, most properties are missing from glib's meson but I already added some and more should be added later. That's bug #795100.
Created attachment 371052 [details] [review] Meson: Add BuildType.Meson to compile recipes Based on code from Nirbheek Chauhan <nirbheek@centricular.com>
Created attachment 371053 [details] [review] Fetch meson and ninja from tarball instead of git
Review of attachment 371052 [details] [review]: lgtm
Review of attachment 371053 [details] [review]: lgtm
Review of attachment 370597 [details] [review]: lgtm
Review of attachment 370596 [details] [review]: lgtm