RELEASING: update instructions to use meson instead of autotools

Signed-off-by Eric Engestrom <[email protected]>

---
 RELEASING | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

RELEASING +8 -19

index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
@@ -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:
 

Signature · 2 lines

Cheers,
  Eric

Quoting Eric Engestrom (2018-12-19 08:23:40)

Quoted 41 lines

Signed-off-by Eric Engestrom <[email protected]>

---
 RELEASING | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

RELEASING +8 -19

index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
@@ -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.
 

RELEASING However, this is up to whoever is driving the feature in question. · line 21

Quoted 1 line

RELEASING +0 -0

   4) Push the updated master branch with the bumped version number:

Quoted 5 lines

RELEASING +0 -1

-- 

Cheers,
Eric

Acked-by Dylan Baker <[email protected]>

But you should probably get someone other than just me to look at this.

Quoted 42 lines · Dylan Baker

Quoting Eric Engestrom (2018-12-19 08:23:40)

Quoted 41 lines

Signed-off-by Eric Engestrom <[email protected]>

---
 RELEASING | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

RELEASING +8 -19

index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
@@ -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.
 

Quoted 1 line

RELEASING However, this is up to whoever is driving the feature in question. · line 21

Quoted 1 line

RELEASING +0 -0

   4) Push the updated master branch with the bumped version number:

Just noticed I forgot to decrement item 4 & 5 :]

Quoted 8 lines

Quoted 5 lines

RELEASING +0 -1

-- 

Cheers,
Eric

Acked-by Dylan Baker <[email protected]>

Quoted 1 line

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).

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 42 lines · Dylan Baker

Quoting Eric Engestrom (2018-12-19 08:23:40)

Quoted 41 lines

Signed-off-by Eric Engestrom <[email protected]>

---
 RELEASING | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

RELEASING +8 -19

index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
@@ -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.
 

Quoted 1 line

RELEASING However, this is up to whoever is driving the feature in question. · line 21

Quoted 1 line

RELEASING +0 -0

   4) Push the updated master branch with the bumped version number:

Just noticed I forgot to decrement item 4 & 5 :]

Quoted 8 lines

Quoted 5 lines

RELEASING +0 -1

--

Cheers,
Eric

Acked-by Dylan Baker <[email protected]>

Quoted 1 line

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).

Quoted 56 lines · Eric Engestrom

Quoted 42 lines · Dylan Baker

Quoting Eric Engestrom (2018-12-19 08:23:40)

Quoted 41 lines

Signed-off-by Eric Engestrom <[email protected]>

---
 RELEASING | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

RELEASING +8 -19

index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
@@ -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.
 

Quoted 1 line

RELEASING However, this is up to whoever is driving the feature in question. · line 21

Quoted 1 line

RELEASING +0 -0

   4) Push the updated master branch with the bumped version number:

Just noticed I forgot to decrement item 4 & 5 :]

Quoted 8 lines

Quoted 5 lines

RELEASING +0 -1

--

Cheers,
Eric

Acked-by Dylan Baker <[email protected]>

Quoted 8 lines

Quoted 1 line

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 :-\

Quoted 73 lines · Emil Velikov

Quoted 56 lines · Eric Engestrom

Quoted 42 lines · Dylan Baker

Quoting Eric Engestrom (2018-12-19 08:23:40)

Quoted 41 lines

Signed-off-by Eric Engestrom <[email protected]>

---
 RELEASING | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

RELEASING +8 -19

index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
@@ -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.
 

Quoted 1 line

RELEASING However, this is up to whoever is driving the feature in question. · line 21

Quoted 1 line

RELEASING +0 -0

   4) Push the updated master branch with the bumped version number:

Just noticed I forgot to decrement item 4 & 5 :]

Quoted 8 lines

Quoted 5 lines

RELEASING +0 -1

--

Cheers,
Eric

Acked-by Dylan Baker <[email protected]>

Quoted 8 lines

Quoted 1 line

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.

Quoted 1 line

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.

Quoted 74 lines · Daniel Vetter

Quoted 73 lines · Emil Velikov

Quoted 56 lines · Eric Engestrom

Quoted 42 lines · Dylan Baker

Quoting Eric Engestrom (2018-12-19 08:23:40)

Quoted 41 lines

Signed-off-by Eric Engestrom <[email protected]>

---
 RELEASING | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

RELEASING +8 -19

index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
@@ -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.
 

Quoted 1 line

RELEASING However, this is up to whoever is driving the feature in question. · line 21

Quoted 1 line

RELEASING +0 -0

   4) Push the updated master branch with the bumped version number:

Just noticed I forgot to decrement item 4 & 5 :]

Quoted 8 lines

Quoted 5 lines

RELEASING +0 -1

--

Cheers,
Eric

Acked-by Dylan Baker <[email protected]>

Quoted 8 lines

Quoted 1 line

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.

Quoted 8 lines

Quoted 1 line

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.

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. This makes it much less likely to accidentally send files with local modifications or add/remove files without meaning to.

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).

Emil, would that be enough, or was your concern something else?

Quoted 93 lines · Daniel Vetter

Quoted 74 lines · Emil Velikov

Quoted 73 lines · Eric Engestrom

Quoted 56 lines · Dylan Baker

Quoted 42 lines

Quoting Eric Engestrom (2018-12-19 08:23:40)

Quoted 41 lines

Signed-off-by Eric Engestrom <[email protected]>

---
 RELEASING | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

RELEASING +8 -19

index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
@@ -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.
 

Quoted 1 line

RELEASING However, this is up to whoever is driving the feature in question. · line 21

Quoted 1 line

RELEASING +0 -0

   4) Push the updated master branch with the bumped version number:

Just noticed I forgot to decrement item 4 & 5 :]

Quoted 8 lines

Quoted 5 lines

RELEASING +0 -1

--

Cheers,
Eric

Acked-by Dylan Baker <[email protected]>

Quoted 8 lines

Quoted 1 line

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.

Quoted 8 lines

Quoted 1 line

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.

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. This makes it much less likely to accidentally send files with local modifications or add/remove files without meaning to.

Like I said though, there's no rush, so let's make sure issues are addressed first.

Quoted 1 line

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.

But there's a bunch of compile-time tests in libdrm, run by ninja test and make check, those should keep working imo, at least for now. -Daniel

Quoted 1 line

Emil, would that be enough, or was your concern something else?

Quoting Daniel Vetter (2019-02-19 07:20:12)

Quoted 86 lines · Eric Engestrom

Quoted 85 lines · Daniel Vetter

Quoted 82 lines · Emil Velikov

Quoted 67 lines · Eric Engestrom

Quoted 56 lines · Dylan Baker

Quoted 42 lines

Quoting Eric Engestrom (2018-12-19 08:23:40)

Quoted 41 lines

Signed-off-by Eric Engestrom <[email protected]>

---
 RELEASING | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

RELEASING +8 -19

index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
@@ -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.
 

Quoted 1 line

RELEASING However, this is up to whoever is driving the feature in question. · line 21

Quoted 1 line

RELEASING +0 -0

   4) Push the updated master branch with the bumped version number:

Just noticed I forgot to decrement item 4 & 5 :]

Quoted 8 lines

Quoted 5 lines

RELEASING +0 -1

--

Cheers,
Eric

Acked-by Dylan Baker <[email protected]>

Quoted 8 lines

Quoted 1 line

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).

Quoted 7 lines

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.

Quoted 2 lines

Quoted 2 lines

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.

Quoted 3 lines

Quoted 3 lines

This makes it much less likely to accidentally send files with local modifications or add/remove files without meaning to.

Quoted 10 lines

Quoted 4 lines

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.

Quoted 88 lines

Quoting Daniel Vetter (2019-02-19 07:20:12)

Quoted 86 lines · Eric Engestrom

Quoted 85 lines · Daniel Vetter

Quoted 82 lines · Emil Velikov

Quoted 67 lines · Eric Engestrom

Quoted 56 lines · Dylan Baker

Quoted 42 lines

Quoting Eric Engestrom (2018-12-19 08:23:40)

Quoted 41 lines

Signed-off-by Eric Engestrom <[email protected]>

---
 RELEASING | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

RELEASING +8 -19

index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
@@ -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.
 

Quoted 1 line

RELEASING However, this is up to whoever is driving the feature in question. · line 21

Quoted 1 line

RELEASING +0 -0

   4) Push the updated master branch with the bumped version number:

Just noticed I forgot to decrement item 4 & 5 :]

Quoted 8 lines

Quoted 5 lines

RELEASING +0 -1

--

Cheers,
Eric

Acked-by Dylan Baker <[email protected]>

Quoted 8 lines

Quoted 1 line

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).

Quoted 7 lines

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

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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 :-)

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

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.

Quoted 11 lines

Quoted 10 lines

Quoted 4 lines

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.

Quoted 5 lines

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

Quoting Emil Velikov (2019-02-19 08:51:18)

Quoted 118 lines · Dylan Baker

Quoted 88 lines

Quoting Daniel Vetter (2019-02-19 07:20:12)

Quoted 86 lines · Eric Engestrom

Quoted 85 lines · Daniel Vetter

Quoted 82 lines · Emil Velikov

Quoted 67 lines · Eric Engestrom

Quoted 56 lines · Dylan Baker

Quoted 42 lines

Quoting Eric Engestrom (2018-12-19 08:23:40)

Quoted 41 lines

Signed-off-by Eric Engestrom <[email protected]>

---
 RELEASING | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

RELEASING +8 -19

index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
@@ -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.
 

Quoted 1 line

RELEASING However, this is up to whoever is driving the feature in question. · line 21

Quoted 1 line

RELEASING +0 -0

   4) Push the updated master branch with the bumped version number:

Just noticed I forgot to decrement item 4 & 5 :]

Quoted 8 lines

Quoted 5 lines

RELEASING +0 -1

--

Cheers,
Eric

Acked-by Dylan Baker <[email protected]>

Quoted 8 lines

Quoted 1 line

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).

Quoted 7 lines

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

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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 :-)

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

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.

Quoted 11 lines

Quoted 10 lines

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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 ¢.