On Fri, Mar 24, 2017 at 2:16 PM, Jose Fonseca wrote: > On 24/03/17 20:08, Kristian Høgsberg wrote: > >> On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca >> wrote: >> >>> On 24/03/17 19:10, Kristian Høgsberg wrote: >>> >>>> >>>> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca >>>> wrote: >>>> >>>>> >>>>> On 23/03/17 01:38, Rob Clark wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray 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@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. >>>>> >>>> >>>> >>>> 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. >>>> >>> >>> >>> There's zero overlap between SCons build users and Meson experience, so I >>> don't see how that would work. Who would lead the charge? >>> >> >> It sounds like Dylan and the Intel team are interested in doing the >> meson work. If that's the case, then perhaps you (or other SCons >> users) would be willing to evaluate the result and see if it meets >> your requirements for a SCons replacement? >> >> Kristian >> > > Evaluating is one thing. Actually migrating is another. > > Brian already said he'd take a look and evaluate. And I'll help in what I > can. I agree we should all evaluate early. > > > But I don't think that the proposal of first migrate scons to meson, then > in a second separate step migrate autotools to meson, is viable. Like I > said: there's no knowledge overlap. The two group of people -- the Meson > and Windows experts -- will be chasing each other tails. And all that > while, the build will continue to be broken or diverge because master dev > will go on. I don't think that's true. I think a decent number of *nix mesa devs will start using meson as their primary build system. Also, we'll definitely be using meson in our CI system because it's so much faster and we have a big workhorse of a build machine. Sure, there will be breakage, but I don't think it will be one-sided.