On 23/03/17 01:38, Rob Clark wrote:
On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <j...@jsg.id.au> wrote:
On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeuc...@gmail.com> wrote:
I guess I'm a little late to the party here, but I haven't had time to
really let all of this sink in and actually look at meson. It doesn't
seem so bad with a quick look and I think I could probably sort it out
when the time came, but there would still be a bit of a learning
curve. While that may not be a big deal at the micro level, I have
concerns at the macro level.
First, I'm concerned it may discourage casual developers and
packagers. autotools isn't great, but most people are familiar enough
with it that they can get by. Most people have enough knowledge of
autotools that they can pretty easily diagnose a configuration based
failure. There are a lot of resources for autotools. I'm not sure
that would be the case for meson. Do we as a community feel we have
enough meson experience to get people over the hump? Anything that
makes it harder for someone to try a new build or do a bisect is a big
problem in my opinion.
One of the things that's prompted this on our side (I've talked this over with
other people at Intel before starting), was that clearly we *don't* know
autotools well enough to get it right. Emil almost always finds cases were we've
done things *almost*, but not quite right.
For my part, it took me about 3 or 4 days of reading through the docs and
writing the libdrm port to get it right, and a lot of that is just the
boilerplate of having ~8 drivers that all need basically the same logic.
Next, my bigger concern is for distro and casual packagers and people
that maintain large build systems with lots of existing custom
configurations. Changing from autotools would basically require many
of these existing tools and systems to be rewritten and then deal with
the debugging and fall out from that. The potential decreased build
time is a nice bonus, but frankly a lot of people/companies have years
of investment in existing tools.
Sure, but we're also not the only ones investigating meson. Gnome is using it
already, libepoxy is using it, gstreamer is using it. There are patches for
weston (written by Daniel Stone) and libinput (written by Peter Hutterer), there
are some other projects in the graphics sphere that people are working on. So
even if we as a community decide that meson isn't for us, it's not going away.
It is worth pointing out that it is currently required by no component
of an x.org stack. In the case of libepoxy it was added by a new maintainer
on a new release and even then autoconf remains.
And as far as I can tell nothing in the entire OpenBSD ports tree
currently requires meson to build including gnome and gstreamer.
but I guess that is conflating two completely different topics..
addition of meson and removal of autotools. It is probably better
that we treat the topics separately. I don't see any way that the two
can happen at the same time.
The autotools build probably needs to remain for at least a couple
releases, and I certainly wouldn't mind if some of the other desktop
projects took the leap of dropping autotools first (at least then
various different "distro" consumers will have already dealt with how
to build meson packages)
None of that blocks addition of a meson build system (or what various
developers use day to day)
BR,
-R
I tend to disagree. While we can't avoid a transitory period, when we
embark on another build system (Meson or something else) I think we
should aim at 1) ensure such tool can indeed _completely_ replace at
least _one_ existing build system, 2) and aim at migration quickly.
Otherwise we'll just end up with yet another build system, yet another
way builds can fail, with some developers stuck on old build systems
because it works, or because the new build system quite doesn't work.
And this is from (painful) experience.
So I think we should identify stake holders soon, collect requirements
(OSes platforms, etc), make sure the prospective tool meets them, have
all stakeholders collaborate on a prototype, them embark on mass migration.
That is, if this fails, let it fail early. If it succeeds, may it
succeed early. Anything but a slow death / zombie life.
BTW, how about migrating mesademos to Meson? It currently has autotools
and cmake. I was hoping that cmake would replace autotools, but I
couldn't run fast enough, so I couldn't practice what preached above,
hence cmake doing almost but not all what autotools does.
And is not a crucial project for Linux distros -- few distros package it
-- and even if they do, no other package would depend on it. And is one
of those sort of projects that should be easy to port to any build too.
Even if we ignore everything else, just replacing autotools + cmake with
just one thing would be a net win.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
