Dylan Baker <dylan@xxxxxxxxxxxxx> writes: > [ Unknown signature status ] > 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". My desire is to push enough of X.org to Meson that I can actually do CI of the X Server. Right now CI is not really tractable on Travis because autogen.sh of all the dependencies takes too long.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
