[Bug 789316] Add Meson support in cerbero

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=789316

--- Comment #67 from Xavier Claessens <xclaesse at gmail.com> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.