Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker <dylan@pnwbakers.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4737 bytes --]

On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeucher@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.

Quoting Rob Clark (2017-03-22 10:07:54)
> I guess an interesting question (from someone who doesn't know meson
> yet) would be whether meson could slurp in the Makefile.sources type
> stuff that we have, which are shared so far between
> android/scons/autotools (and for the most part, kept developers from
> having to care *too* much about the different build systems)

Jason and I have talked about that too. I'd suggested that we could write a
module for meson to read makefile.sources (since we're surely not the only
project that would benefit from such a module), except that android is moving to
blueprint[1] instead of android.mk files. As far as I can tell blueprint doesn't
support using makefile.sources, so it seems somewhat moot in a world of
blueprint for android, meson for *.

I don't think that meson should try to generate blueprint files, since blueprint
is itself a metabuild system that generates ninja files, and is self
boot-strapping Go code. I don't know if the community is going to want blueprint
to live in repo either, since one actually writes Go code for the build system.
(I'm not objecting prematurely, I'm just pointing out that the design is
significantly different the Android.mk, and the community will probably want to
re-evaluate)

If android doesn't mandate a migration to blueprint, or blueprint does handle
makefile.sources (I don't think it does), I'd be happy to propose a module for
meson that could read makefile.sources, and write said module, and get said
module upstream.

[1] https://godoc.org/github.com/google/blueprint
> 
> If so, that makes it easier to coexist with existing build systems.  I
> don't think it would be a good idea to remove the autotools build
> anytime soon.. that should be the last one removed, after meson has
> replaced scons (and hopefully android?)

I would imagine that if we did merge meson, we would make at the very least one
release with meson and autotools (scons is VMWare's thing, they can migrate at
their leisure), if not two, to give us a chance to flush out the bugs and to
give various distros who don't have meson ready yet a chance. It'll also give
the fast moving and aggressive distros like Arch and Fedora and chance to
migrate and report bugs.

Dylan

[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljS2iYACgkQCJ4WlhQG
iO850wf8DJMpoNlKFu/vqC5BRmp6+jT57dfq4ayrzjlceeHYtYANDp91DoYzaJyB
STQ2H84K8f7bcpJkIuh58bhJm+udtqskXErSJCjC4VzeStKiFC+J0k+PqgaOSR7x
B0oT2EJ/c77gw9PU22SlTAjXTcalCIa7Me0ehLBEgv1LgSg4PewKot1/Jeavs+60
ED3wYLBMo9aUoU+MSnzXKI2PAjNZjnQSVJQB5J0Tzhp1UAf4rPjD6qwJ4M2EMEbw
wLsvx4XqXInkVpTzVggld14OwkB5UidEt1soi50Bhwe8GunFDJ95qT3BRCpdKwYF
v+KZsjgwusbvJktPZ6W5w1/Cdd4MWA==
=QWz+
-----END PGP SIGNATURE-----

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel