Quoting Jose Fonseca (2017-03-24 06:42:18) > > 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. I tend to agree. Meson is *nice* because it's faster than autotools, but it's simplicity and the fact that it works for windows and *nix systems is one of the best features. Having fewer build systems is better than more. We had hoped that we could do one release with both autotools and meson, to give some of the fast moving linux distributions (Arch, Fedora, etc) a chance to help us iron out bugs, especially for pacakgers. I think it is important though to make a commitment for exactly when we're going to either migrate completely to meson, or abandon the attempt and revert it. > 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. I have a branch that builds intel's Vulkan driver, I'm actively working to get intel's i965 dri driver and llvmpipe building and send that out as an RFC to mesa-dev. That should give us enough of mesa to evaluate the build system I hope (Since it touches all of the major mesa components [classic, gallium, neither]). If other people are interested in collaborating I'd be happy to push the branch sooner so that others can look at it. I also think it's worth talking to Eric (who said he's porting X to meson), Daniel Stone (who has patches to port weston to meson), and Peter Hutterer (who has patches to port libinput to meson). If they're serious about seeing those land meson is even more appealing, since it would be a single build system that all of the *nix graphics stack would be moving towards, and would mean that we wouldn't have an "Autotools for xorg", "meson for weston and libinput", "cmake for piglit", and "<other build system> for mesa". > 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. That's definitely doable, but most distros do package it, it's where glxgears, and more importantly glxinfo live. I'll have a look at it and see. At the very least we should be able to drop cmake since I very much doubt anyone but you guys use it. > Even if we ignore everything else, just replacing autotools + cmake with > just one thing would be a net win. > > > Jose
Attachment:
signature.asc
Description: signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
