On Fri, Mar 24, 2017 at 3:10 PM, Kristian Høgsberg <hoegsberg@xxxxxxxxx> wrote: > On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca <jfonseca@xxxxxxxxxx> wrote: >> On 23/03/17 01:38, Rob Clark wrote: >>> >>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <jsg@xxxxxxxxx> 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 <alexdeucher@xxxxxxxxx> >>>>> 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. > > I agree, adding a meson build system should aim to phase out one of > the other build systems within one or two release cycles. But (and > maybe that was Robs point) that doesn't have be autotools. What if we > phase out scons? It doesn't seem like anybody is really attached to it > and if meson is as good as scons on windows, then if nothing else > happens we end up with the same number of build systems. What's more > likely to happen is that a lot of Linux developers (and CI systems) > will also start using meson, which means that life gets easier for > vmware wrt maintaining the build system, and easier for all developers > who have spent to much of their life waiting for autogen.sh. Then > decommissioning autotools can be a separate topic as Rob suggests, > something we'll do when the world is ready. yup, that was basically my point.. scons seemed like an easier first target BR, -R > Kristian > >> >> >> 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@xxxxxxxxxxxxxxxxxxxxx >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
