[PATCH libdrm] RELEASING: update instructions to use meson instead of autotools

Thu Feb 21 09:42:48 UTC 2019

On Tue, Feb 19, 2019 at 02:33:04PM -0800, Dylan Baker wrote:
> Quoting Emil Velikov (2019-02-19 08:51:18)
> > On Tue, 19 Feb 2019 at 15:36, Dylan Baker <dylan at pnwbakers.com> wrote:
> > >
> > > Quoting Daniel Vetter (2019-02-19 07:20:12)
> > > > On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom <eric.engestrom at intel.com> wrote:
> > > > >
> > > > > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > > > > > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov <emil.l.velikov at gmail.com> wrote:
> > > > > > >
> > > > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom <eric.engestrom at intel.com> wrote:
> > > > > > > >
> > > > > > > > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > > > > > > > > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > > > > > > > > Signed-off-by: Eric Engestrom <eric.engestrom at intel.com>
> > > > > > > > > > ---
> > > > > > > > > >  RELEASING | 27 ++++++++-------------------
> > > > > > > > > >  1 file changed, 8 insertions(+), 19 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/RELEASING b/RELEASING
> > > > > > > > > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > > > > > > > > > --- a/RELEASING
> > > > > > > > > > +++ b/RELEASING
> > > > > > > > > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving the feature in question.
> > > > > > > > > >
> > > > > > > > > >  Follow these steps to release a new version of libdrm:
> > > > > > > > > >
> > > > > > > > > > -  1) Bump the version number in configure.ac and meson.build. We seem
> > > > > > > > > > -     to have settled for 2.4.x as the versioning scheme for libdrm, so
> > > > > > > > > > -     just bump the  micro version.
> > > > > > > > > > -
> > > > > > > > > > -  2) Run autoconf and then re-run ./configure so the build system
> > > > > > > > > > -     picks up the new version number.
> > > > > > > > > > -
> > > > > > > > > > -  3) Verify that the code passes "make distcheck".  Running "make
> > > > > > > > > > -     distcheck" should result in no warnings or errors and end with a
> > > > > > > > > > -     message of the form:
> > > > > > > > > > -
> > > > > > > > > > -       =============================================
> > > > > > > > > > -       libdrm-X.Y.Z archives ready for distribution:
> > > > > > > > > > -       libdrm-X.Y.Z.tar.gz
> > > > > > > > > > -       libdrm-X.Y.Z.tar.bz2
> > > > > > > > > > -       =============================================
> > > > > > > > > > -
> > > > > > > > > > -     Make sure that the version number reported by distcheck and in
> > > > > > > > > > -     the tarball names matches the number you bumped to in configure.ac.
> > > > > > > > > > +  1) Bump the version number in meson.build. We seem to have settled for
> > > > > > > > > > +     2.4.x as the versioning scheme for libdrm, so just bump the micro
> > > > > > > > > > +     version.
> > > > > > > > > > +
> > > > > > > > > > +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> > > > > > > > > > +     Make sure that the version number of the tarball name in
> > > > > > > > > > +     builddir/meson-dist/ matches the number you bumped to. Move that
> > > > > > > > > > +     tarball to the libdrm repo root for the release script to pick up.
> > > > > > > > > >
> > > > > > > > > >    4) Push the updated master branch with the bumped version number:
> > > > > > > >
> > > > > > > > Just noticed I forgot to decrement item 4 & 5 :]
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Cheers,
> > > > > > > > > >   Eric
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Acked-by: Dylan Baker <dylan at pnwbakers.com>
> > > > > > > > >
> > > > > > > > > But you should probably get someone other than just me to look at this.
> > > > > > > >
> > > > > > > > There is no "libdrm maintainer", which makes everyone a libdrm
> > > > > > > > maintainer :]
> > > > > > > >
> > > > > > > > If nobody object, I'll push this in a few weeks (there's really no rush,
> > > > > > > > but I want to make that move at some point, we have no reason to stay
> > > > > > > > dependant on autotools now that we have better tools).
> > > > > > >
> > > > > > > Must admit I'm not the biggest fan. I can see this being cool for the
> > > > > > > maintainer, if autotools was was present on their system.
> > > > > > > The unfortunate reality is - it's there for the foreseeable future.
> > > > > > > If anything it makes it more annoying for those using autotools/make -
> > > > > > > regardless if they like doing so or not.
> > > > > > >
> > > > > > > So that's a nack from me :-\
> > > > > >
> > > > > > Not really following what's the downside is of using meson to cut the
> > > > > > release tarball? Resulting tarball should still be able to build fine
> > > > > > with automake. If the concern is that automake will bitrot, then I
> > > > > > think a much better solution is to add a few automake targets to the
> > > > > > gitlab ci autobuilder stuff. That's what we've done for igt at least,
> > > > > > works neatly.
> > > > >
> > meson dist is effectively a git tarball. Hence one cannot simply
> > "./configure && make" it
> > 
> > > > > Agreed, and to me using meson has a huge upside: it packages what's in git,
> > > > > unlike autotools which packages whatever was on your machine at the time.
> > If meson doesn't use any of the extra files that is fine. I'm not
> > saying it should :-)
> > 
> > > > > This makes it much less likely to accidentally send files with local
> > > > > modifications or add/remove files without meaning to.
> > > > >
> > The release tooling handles that amongst other things.
> > 
> > > > > Like I said though, there's no rush, so let's make sure issues are
> > > > > addressed first.
> > > > >
> > > > > I'll add a CI job to run `make distcheck` on releases (libdrm-* tags).
> > > >
> > > > I'd go with make check only. make distcheck needs all the manual
> > > > fiddling in makefile templates (EXTRA_DIST and friends) since automake
> > > > doesn't do the right thing by default like meson. If we go with meson
> > > > for making release tarballs, I don't think it makes sense to keep the
> > > > automake stuff alive.
> > >
> > > I agree with this. Getting a tarball with an autogen.sh and not a configure
> > > script (i.e., unbootstrapped) is unexpected with autotools. When we move to
> > > using meson to build the dist tarball we should drop autotools at the same time
> > > or shortly after.
> > >
> > If it doesn't get in one's way what's the point of killing it?
> > Practically all the issues I've seen so far are people not running
> > make check/ninja test :-(
> > 
> > While I'm a fan of meson for the speed, there are no concerns from
> > having a more established alternative around.
> > 
> > -Emil
> 
> Personally I see two problems with keeping autotools:
> 
> 1) We have to keep maintaining it. As more and more people use meson then
>    autotools will bitrot (We've seen this in mesa already). Eventually the
>    tribal knowledge will be "don't use autotools, it's broken", but people who
>    aren't in the tribe wont know that and will be (rightfully) frustrated.
> 
> 2) while autotools expects a bootstrapped tarbal (generated files) meson
>    doesn't, and this can lead to cases where ninja should regenerate a source
>    because something has changed, but doesn't.
> 
> Again, just my two ¢.

Yeah I don't think maintaining 2 build systems is a good idea long term.
At least for igt the plan is to sunset autoconf fairly aggressively, only
thing you can still build with autoconf are the tests/tools. Everything
around it (docs, manpages, selftests, ...) is already meson only. I think
once most of the projects requiring libdrm dumped autoconf, we should dump
it too from libdrm. And that seems well on its way already.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch