* [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools @ 2018-12-19 16:23 Eric Engestrom 2018-12-20 19:53 ` Dylan Baker 0 siblings, 1 reply; 12+ messages in thread From: Eric Engestrom @ 2018-12-19 16:23 UTC (permalink / raw) To: dri-devel Signed-off-by: Eric Engestrom <eric.engestrom@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: -- Cheers, Eric _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools 2018-12-19 16:23 [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools Eric Engestrom @ 2018-12-20 19:53 ` Dylan Baker 2019-02-18 17:42 ` Eric Engestrom 0 siblings, 1 reply; 12+ messages in thread From: Dylan Baker @ 2018-12-20 19:53 UTC (permalink / raw) To: Eric Engestrom, dri-devel [-- Attachment #1.1: Type: text/plain, Size: 2078 bytes --] Quoting Eric Engestrom (2018-12-19 08:23:40) > Signed-off-by: Eric Engestrom <eric.engestrom@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: > > -- > Cheers, > Eric > Acked-by: Dylan Baker <dylan@pnwbakers.com> But you should probably get someone other than just me to look at this. [-- Attachment #1.2: signature --] [-- Type: application/pgp-signature, Size: 228 bytes --] -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRxxLdWILx1cItL2yVMlfqrPrBz7AUCXBvzJwAKCRBMlfqrPrBz 7PzFAQClsGsmlCfSlGeamOeOC2uCZSCjpzc9pXpMpfa/MXC+fgD/SUKwQtfWbjhX g2QF92XYDjtrAk8xrmpx6e6WqiRx2Qg= =BvKZ -----END PGP SIGNATURE----- [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools 2018-12-20 19:53 ` Dylan Baker @ 2019-02-18 17:42 ` Eric Engestrom 2019-02-18 20:36 ` Daniel Vetter 2019-02-19 11:52 ` Emil Velikov 0 siblings, 2 replies; 12+ messages in thread From: Eric Engestrom @ 2019-02-18 17:42 UTC (permalink / raw) To: dri-devel; +Cc: Dylan Baker 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@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@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). _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools 2019-02-18 17:42 ` Eric Engestrom @ 2019-02-18 20:36 ` Daniel Vetter 2019-02-19 11:52 ` Emil Velikov 1 sibling, 0 replies; 12+ messages in thread From: Daniel Vetter @ 2019-02-18 20:36 UTC (permalink / raw) To: Eric Engestrom; +Cc: dri-devel, Dylan Baker On Mon, Feb 18, 2019 at 05:42:38PM +0000, Eric Engestrom 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@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@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). I double-checked that ninja dist does run the tests, so lgtm (with the numbering adjusted): Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools 2019-02-18 17:42 ` Eric Engestrom 2019-02-18 20:36 ` Daniel Vetter @ 2019-02-19 11:52 ` Emil Velikov 2019-02-19 12:53 ` Daniel Vetter 1 sibling, 1 reply; 12+ messages in thread From: Emil Velikov @ 2019-02-19 11:52 UTC (permalink / raw) To: Eric Engestrom; +Cc: ML dri-devel, Dylan Baker On Mon, 18 Feb 2019 at 17:42, Eric Engestrom <eric.engestrom@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@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@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 :-\ -Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools 2019-02-19 11:52 ` Emil Velikov @ 2019-02-19 12:53 ` Daniel Vetter 2019-02-19 14:02 ` Eric Engestrom 0 siblings, 1 reply; 12+ messages in thread From: Daniel Vetter @ 2019-02-19 12:53 UTC (permalink / raw) To: Emil Velikov; +Cc: Eric Engestrom, ML dri-devel, Dylan Baker On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov <emil.l.velikov@gmail.com> wrote: > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom <eric.engestrom@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@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@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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools 2019-02-19 12:53 ` Daniel Vetter @ 2019-02-19 14:02 ` Eric Engestrom 2019-02-19 15:20 ` Daniel Vetter 0 siblings, 1 reply; 12+ messages in thread From: Eric Engestrom @ 2019-02-19 14:02 UTC (permalink / raw) To: Daniel Vetter; +Cc: Emil Velikov, ML dri-devel, Dylan Baker 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@gmail.com> wrote: > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom <eric.engestrom@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@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@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. 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? _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools 2019-02-19 14:02 ` Eric Engestrom @ 2019-02-19 15:20 ` Daniel Vetter 2019-02-19 15:34 ` Dylan Baker 0 siblings, 1 reply; 12+ messages in thread From: Daniel Vetter @ 2019-02-19 15:20 UTC (permalink / raw) To: Eric Engestrom; +Cc: Emil Velikov, ML dri-devel, Dylan Baker On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom <eric.engestrom@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@gmail.com> wrote: > > > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom <eric.engestrom@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@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@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. > > 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). 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 > Emil, would that be enough, or was your concern something else? -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools 2019-02-19 15:20 ` Daniel Vetter @ 2019-02-19 15:34 ` Dylan Baker 2019-02-19 16:51 ` Emil Velikov 0 siblings, 1 reply; 12+ messages in thread From: Dylan Baker @ 2019-02-19 15:34 UTC (permalink / raw) To: Daniel Vetter, Eric Engestrom; +Cc: Emil Velikov, ML dri-devel [-- Attachment #1.1: Type: text/plain, Size: 5716 bytes --] Quoting Daniel Vetter (2019-02-19 07:20:12) > On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom <eric.engestrom@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@gmail.com> wrote: > > > > > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom <eric.engestrom@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@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@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. > > > > 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). > > 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. Just my two ¢. Dylan > > 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 > > > Emil, would that be enough, or was your concern something else? [-- Attachment #1.2: signature --] [-- Type: application/pgp-signature, Size: 228 bytes --] -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRxxLdWILx1cItL2yVMlfqrPrBz7AUCXGwh/wAKCRBMlfqrPrBz 7EFHAP0dMnnQQJGK0Zm1pBaOhblmx3WIcgyMHsGlrttBnjxGQgEA3SZoZ0TgLXu8 g2jnnMwkFXMr70HjYLa0ciJEuBZSSwY= =Nh52 -----END PGP SIGNATURE----- [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools 2019-02-19 15:34 ` Dylan Baker @ 2019-02-19 16:51 ` Emil Velikov 2019-02-19 22:33 ` Dylan Baker 0 siblings, 1 reply; 12+ messages in thread From: Emil Velikov @ 2019-02-19 16:51 UTC (permalink / raw) To: Dylan Baker; +Cc: Eric Engestrom, ML dri-devel On Tue, 19 Feb 2019 at 15:36, Dylan Baker <dylan@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@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@gmail.com> wrote: > > > > > > > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom <eric.engestrom@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@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@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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools 2019-02-19 16:51 ` Emil Velikov @ 2019-02-19 22:33 ` Dylan Baker 2019-02-21 9:42 ` Daniel Vetter 0 siblings, 1 reply; 12+ messages in thread From: Dylan Baker @ 2019-02-19 22:33 UTC (permalink / raw) To: Emil Velikov; +Cc: Eric Engestrom, ML dri-devel [-- Attachment #1.1: Type: text/plain, Size: 7174 bytes --] Quoting Emil Velikov (2019-02-19 08:51:18) > On Tue, 19 Feb 2019 at 15:36, Dylan Baker <dylan@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@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@gmail.com> wrote: > > > > > > > > > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom <eric.engestrom@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@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@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 ¢. Dylan [-- Attachment #1.2: signature --] [-- Type: application/pgp-signature, Size: 228 bytes --] -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRxxLdWILx1cItL2yVMlfqrPrBz7AUCXGyEIAAKCRBMlfqrPrBz 7MbDAQCx2YyhzmvQHQt0EA9sI4caN9ktIpbFy6IskHGUSszqJgEAwHg6VZZQtOT8 XYv5ZXQpaJtt1eamEjeRTj/CfbiC7QI= =IYNz -----END PGP SIGNATURE----- [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools 2019-02-19 22:33 ` Dylan Baker @ 2019-02-21 9:42 ` Daniel Vetter 0 siblings, 0 replies; 12+ messages in thread From: Daniel Vetter @ 2019-02-21 9:42 UTC (permalink / raw) To: Dylan Baker; +Cc: Eric Engestrom, Emil Velikov, ML dri-devel 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@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@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@gmail.com> wrote: > > > > > > > > > > > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom <eric.engestrom@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@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@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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-02-21 9:42 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-12-19 16:23 [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools Eric Engestrom 2018-12-20 19:53 ` Dylan Baker 2019-02-18 17:42 ` Eric Engestrom 2019-02-18 20:36 ` Daniel Vetter 2019-02-19 11:52 ` Emil Velikov 2019-02-19 12:53 ` Daniel Vetter 2019-02-19 14:02 ` Eric Engestrom 2019-02-19 15:20 ` Daniel Vetter 2019-02-19 15:34 ` Dylan Baker 2019-02-19 16:51 ` Emil Velikov 2019-02-19 22:33 ` Dylan Baker 2019-02-21 9:42 ` Daniel Vetter
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.