On Fri, Mar 24, 2017 at 5:16 PM, Jose Fonseca <jfonseca@xxxxxxxxxx> wrote: > On 24/03/17 20:08, Kristian Høgsberg wrote: >> >> On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca <jfonseca@xxxxxxxxxx> >> wrote: >>> >>> On 24/03/17 19:10, Kristian Høgsberg 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. >>> >>> >>> >>> 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. > Well, I didn't mean to imply that we would remove scons before you were ready.. as with autotools we can't yank the rug out. But my theory is that, unlike scons build, since there will be a good number of devs using meson day to day on *nix, hopefully that translates into less fixing up the build for windows on your end and you will prefer to switch ;-) I think we'll have to evaluate as we go, but covering the windows build use-case seems like an easier first target than every corner-case that autotools handles. BR, -R _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
