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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
