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 <[email protected]> wrote: > > > > > > Quoting Daniel Vetter (2019-02-19 07:20:12) > > > > On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom > > > > <[email protected]> wrote: > > > > > > > > > > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote: > > > > > > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom > > > > > > > <[email protected]> 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 <[email protected]> > > > > > > > > > > --- > > > > > > > > > > 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 <[email protected]> > > > > > > > > > > > > > > > > > > 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 [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
