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

[Emil Velikov]

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