Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Bastien Nocera]

On Thu, 2016-10-13 at 10:18 -0500, Michael Catanzaro wrote:
> On Thu, 2016-10-13 at 11:53 +0100, Sam Thursfield wrote:
> > Would a GNOME-goal to ensure that every project follows the Build
> > API
> > help
> > here?
> 
> 
> What do the meson developers think about the Build API?
> 
> I think I would not support such a goal. I do not want to add a
> boilerplate fake configure script to my project, nor a fake Makefile
> to
> a project that doesn't use make at all. I want to have fewer build
> system files to worry about, not more.

This "build API" is also what Flatpak expects. It's also baked in a
number of package build systems.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Michael Catanzaro]

On Thu, 2016-10-13 at 11:53 +0100, Sam Thursfield wrote:
> Would a GNOME-goal to ensure that every project follows the Build API
> help
> here?

What do the meson developers think about the Build API?

I think I would not support such a goal. I do not want to add a
boilerplate fake configure script to my project, nor a fake Makefile to
a project that doesn't use make at all. I want to have fewer build
system files to worry about, not more.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Nirbheek Chauhan]

Hello,

On Thu, Oct 13, 2016 at 4:23 PM, Sam Thursfield  wrote:
> I agree with the sentiments above that Meson isn't quite ready for this
> yet. I've tried Meson out for 2 projects (Tracker and Rhythmbox) and in
> both cases there have been several patches needed to Meson, some of
> which are still unfinished.
>
> Many people other people seem to be trying out Meson already, which is
> good, and suggests we don't need to do anything further right now to
> encourage people to try it out.
>

Yes, the GNOME module in Meson has had several improvements merged,
and more in the pipeline. Thanks for your patches!

We've been hard at work to make everything work smoothly for GNOME
projects, and have had a lot of interest; particularly from the Vala
folks. It's quite encouraging! Our goal is to have GNOME and Vala
support working flawlessly out of the box ASAP, and people coming and
telling us what they need has been a great help in that regard.

If you are thinking about trying Meson out and need help, hop on to
#mesonbuild on Freenode and find us. :-)

PS: We'd really like some help in making our documentation more newbie
friendly too.

> There are GStreamer build instructions using Meson at
>  (and /gst-plugins-*/) which
> seem pretty complete and I believe they're already being used to
> cross-compile GStreamer to Windows.
>

Just bunch of small corrections. The GStreamer Meson build files have
been merged upstream (alongside Autotools), so it is recommended that
you get them from there:

https://cgit.freedesktop.org/gstreamer/gstreamer/

+ /gst-plugins-{base,good,bad,ugly}, etc.

We also have a git repo that uses Meson's subproject feature to build
gstreamer + plugins in one tree in one go:
https://github.com/thiblahute/gst-all . This is the recommended way of
building GStreamer with Meson on Linux using the system-install
dependencies.

We have our own "jhbuild/continuous-equivalent" called Cerbero that is
used for building GStreamer in other configurations. The default build
used there is still Autotools. For that, we have a branch
(https://github.com/centricular/cerbero) that can build gstreamer +
plugins on Linux, on native Windows, and can cross-compile to Windows
on Linux.

> For GTK+, there are preliminary build instructions for GTK+ at
> . I guess it would be
> a few days work to make these nearly-complete. So I think Meson is close
> to being able to pass that test already.
>

There's also a Glib repository with Meson build files
(https://github.com/centricular/glib), but just like the GTK+ build
it's not complete yet, and we're working on making it have
feature-parity with the Autotools build and the Visual Studio project
files shipped with the project. It's just a matter of going over the
Autotools build files line by line and checking that everything has
been translated over.

Cheers,

-- 
~Nirbheek Chauhan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Sam Thursfield]

On 05/10/16 15:39, Michael Biebl wrote:
>As much as I hate autotools and its arcane syntax, it does bring
>uniformity and consistency.
>Atm I'm counting waf (for some non-core modules), autotools, cmake and
>some are discussing to use meson/ninja.

>So while I'm not tied to autotools, I would hate to see if every
>modules maintainer chooses his/her own build system of choice. This
>makes it really cumbersome as downstream/integrator.

Would a GNOME-goal to ensure that every project follows the Build API help
here?

I feel that should be tied up with improvements to build-api.git that make it
trivial for CMake and Meson projects to achieve Build API compatibility
provided they follow certain conventions.

On 10/10/16 9:49, Sebastian Geiger (Lanoxx) wrote:
> This would of course mean that we already know meson will be the build
> system of choice and that it fits the needs of all modules. Of course
> individual module maintainers would still be free to make a different
> choice or to stick with autotools but we would at least have something
> to motivate the migration, to track its status across all modules and
> it would be a push to towards some level of consistency. Also we could
> collect some best practices from modules that have already done the
> conversion on a Gnome Goal page.

I agree with the sentiments above that Meson isn't quite ready for this
yet. I've tried Meson out for 2 projects (Tracker and Rhythmbox) and in
both cases there have been several patches needed to Meson, some of
which are still unfinished.

Many people other people seem to be trying out Meson already, which is
good, and suggests we don't need to do anything further right now to
encourage people to try it out.

Later on, I agree as well that we should encourage switching away from
Autotools, and recommend (but not mandate) Meson as its replacement.

Both CMake and Meson are much faster than Autotools (like, 3 second
vs. 30 second reconfigure time); so as developers & system integrators
we get a clear benefit.

When writing build instructions I definitely prefer Meson over CMake,
due to CMake's confusing failure cases[1], huge amount of cruft[2],
the strange preference for manually maintained FindPkg* modules over
upstream pkg-config files, and other things. However, making simple
changes to a CMake build system is pretty intuitive so as long as
someone else went through the initial pain of writing them, it's fine
:-)

1. e.g. https://samthursfield.wordpress.com/2015/11/21/
2. e.g. https://cmake.org/cmake/help/v3.4/manual/cmake-properties.7.html


On 10/10/16 at 2:51PM, Tristan Van Berkom wrote:
> I'm not familiar with Meson myself but have had to go through numerous
> headaches dealing with CMake ported projects which tended to build
> well on the maintainers computer but not on mine, or not withstand to
> a cross compile properly. CMake (and it's userbase) is/are starting to
> be mature and these problems are fewer and further between.

CMake has had decent cross-compile support for a while, you just create
a 'toolchain file'. Here's the toolchain file template used by the
Buildroot build
system for example:
.

Meson's works in pretty much the same way:


The state of the art for cross compilation with Autoconf is also to
manually pass in all the config flags that it can't figure out for
itself, e.g.

  http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/mips64-64/temp-system/bash.html
  
http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/mips64-64/temp-system/coreutils.html
  http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/mips64-64/temp-system/tar.html

> I would caution against using only JHBuild as a metric for Meson's
> maturity. Rather I would recommend starting at the lower end of the
> stack, say try to port glib/GTK+ over to use Meson in a wip branch, and
> then see how that withstands a cross compile to arm in a wip branch
> against Yocto poky master.

Agreed, that seems a good test (although I'd test with Buildroot :-).

There are GStreamer build instructions using Meson at
 (and /gst-plugins-*/) which
seem pretty complete and I believe they're already being used to
cross-compile GStreamer to Windows.

For GTK+, there are preliminary build instructions for GTK+ at
. I guess it would be
a few days work to make these nearly-complete. So I think Meson is close
to being able to pass that test already.

Sam
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some dudes opinion on Ctrl-Tab

[Peter Hutterer]

On Thu, Oct 13, 2016 at 10:27:43AM +0100, Sam Thursfield wrote:
> On 9/17/16, Daniel Beecham  wrote:
> > + All major web browsers (Firefox, Chrome, Edge, Internet Explorer, Opera,
> > Midori and others) use ctrl-tab to switch tab. Neither  nor
> >  consumes tab in any of these browsers, it's just used to change
> > focus.
> 
> Cool, I never realised because those that I use also allow tab
> switching with ctrl+pgup and ctrl+pgdn.
> 
> ...
> 
> > * The argument of obviousness ("don't make me think", or "great design is
> > invisible")
> >
> > Ctrl-tab is such an ubiquitous binding by now, that users just sort of
> > expect it. I saw a design talk by some designer on google the other day,
> > and she talked about how they'd just plop a UI in front of people and see
> > what they'd do - and then make the UI such that those interactions made
> > sense. Like A/B testing a'la extreme. You want an interface which is
> > obvious, which makes sense, is intuitive, doesn't get in your way. Those
> > are the successful interfaces. ctrl-tab is obvious.
> 
> Is your point here that people who've never used a computer before
> will figure out that ctrl-tab switches tabs without any kind of
> instruction, but will not figure out that ctrl-pgup and ctrl-pgdn
> switch tabs unless someone tells them? I find that hard to believe
> without evidence. Maybe I'm missing your point.

I didn't know that...

Cheers,
   Peter
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some dudes opinion on Ctrl-Tab

[Sam Thursfield]

On 9/17/16, Daniel Beecham  wrote:
> + All major web browsers (Firefox, Chrome, Edge, Internet Explorer, Opera,
> Midori and others) use ctrl-tab to switch tab. Neither  nor
>  consumes tab in any of these browsers, it's just used to change
> focus.

Cool, I never realised because those that I use also allow tab
switching with ctrl+pgup and ctrl+pgdn.

...

> * The argument of obviousness ("don't make me think", or "great design is
> invisible")
>
> Ctrl-tab is such an ubiquitous binding by now, that users just sort of
> expect it. I saw a design talk by some designer on google the other day,
> and she talked about how they'd just plop a UI in front of people and see
> what they'd do - and then make the UI such that those interactions made
> sense. Like A/B testing a'la extreme. You want an interface which is
> obvious, which makes sense, is intuitive, doesn't get in your way. Those
> are the successful interfaces. ctrl-tab is obvious.

Is your point here that people who've never used a computer before
will figure out that ctrl-tab switches tabs without any kind of
instruction, but will not figure out that ctrl-pgup and ctrl-pgdn
switch tabs unless someone tells them? I find that hard to believe
without evidence. Maybe I'm missing your point.

Sam
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list