[Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

Jason Ekstrand jason at jlekstrand.net
Sun Dec 16 23:44:52 UTC 2018


On Sun, Dec 16, 2018 at 11:40 AM Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny <gw.fossdev at gmail.com> wrote:
> >
> > Since Meson will eventually be the only build system deprecate autotools
> > now. It can still be used by invoking configure with the flag
> >   --enable-autotools
> >
> > Signed-off-by: Gert Wollny <gw.fossdev at gmail.com>
> > ---
> > IMO autotools should be properly deprecated prior it its removal, so here
> > is a patch to do just that. I think autotools should be marked as
> deprecated
> > for the 19.0 release and, depending on feedback, it could be removed
> with 19.1.
> > Anyway, in the end it's up to the release team how to handle this.
>
> I think too many usability issues are left over in meson to make it
> the recommended build system, and remove the system that everyone
> knows how to use. If people want to use meson that's fine, but a
> number of concerns have been surfaced which make it currently
> unsuitable. I plan on doing a longer write-up covering some of the
> things I've mentioned in the past along with some new ones.
>

This patch doesn't remove anything, it just changes the recommendation and
annoys people who use autotools.  Unless I've missed something, all of the
issues stated so far have been usability annoyances having to do with
re-building.  Nothing remains which prevents you from building the project
and some user who comes along randomly and wants to build mesa should be
able to use meson just fine.


> If the concern is that there are 2 build systems and it's unclear
> which to use, I'd definitely err on the side of making meson the one
> requiring extra hoops to jump through.
>

Right now, we have a chicken and egg problem.  Dylan has worked like crazy
to solve the blocking issues and, at this point, mesa is buildable with
meson in more-or-less all the configurations as autotools allows.  What
remains are a few useability issues.  The only way we'll solve those issues
is if people try meson and report them.  Given that most of the excited
early adopters are now pretty happy with it, what remains is to solve the
useability issues of those less excited.  As long as meson remains an
optional thing and autotools safe for the indefinite future, those less
excited will continue to ignore meson, use autotools, and not have their
problems solved.  As long as people insist on meson being deprecated until
100% of the issues are solved, the people trying to make meson happen have
a moving target and we'll keep running around in circles forever.  I don't
know how to move things forward without somehow forcing the issue a bit.  I
think Dylan's e-mail was reasonably effective at flushing out some of those
issues; this patch just goes a bit further.

I'm not trying to belittle the issues you've had in any way.  However,
we've had the meson build system in the works for over a year now and some
of us have been using almost nothing else for the 8 or 10 months of that.
The fact that some of these issues are just now surfacing is a bit
disappointing.  What we need is a concrete point at which we can declare
meson good enough and get rid of the legacy system.  Previously, Dylan and
the rest had been working under the assumption that the relevant milestone
was the ability to build mesa on Linux with all the same combinations as
were supported by autotools minus the couple which we decided to drop.
That milestone has been achieved.  Some of the feedback we heard on the
previous e-mail thread was that that isn't sufficient.  That's fine but the
question remains, what is sufficient?  It would be helpful if, along with
your list of issues, you would provide an indication of what you think the
"good enough" point is.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181216/0fb1e321/attachment-0001.html>


More information about the mesa-dev mailing list