[PATCH util-modular] release.sh: add support for meson projects

[Peter Hutterer]

On Fri, Sep 29, 2017 at 12:47:32PM +0100, Emil Velikov wrote:
> Hi Peter,
> 
> A couple of ideas how to make this a bit easier to read.
> 
> Before all :
> Any objections on splitting process_module() a bit? Currently its over
> 400 lines :-\
> 
> On 28 September 2017 at 06:12, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> > ---
> >  release.sh | 155 +++++++++++++++++++++++++++++++++++++++----------------------
> >  1 file changed, 99 insertions(+), 56 deletions(-)
> >
> > diff --git a/release.sh b/release.sh
> > index ff89d2e..afa43ac 100755
> > --- a/release.sh
> > +++ b/release.sh
> > @@ -125,6 +125,7 @@ git tag: $tag_name
> >  RELEASE
> >
> >      for tarball in $tarbz2 $targz $tarxz; do
> > +       tarball=`basename $tarball`
> >         cat <<RELEASE
> >  https://$host_current/$section_path/$tarball
> >  MD5:  `$MD5SUM $tarball`
> > @@ -311,6 +312,9 @@ sign_or_fail() {
> >  #
> >  process_module() {
> >
> > +    local use_autogen=0
> > +    local use_meson=0
> > +
> >      top_src=`pwd`
> >      echo ""
> >      echo "========  Processing \"$top_src/$MODULE_RPATH\""
> > @@ -358,70 +362,107 @@ process_module() {
> >         return 1
> >      fi
> >
> > -    # If AC_CONFIG_AUX_DIR isn't set
> Speaking of which perhaps I should send some of my local patches on
> the topic ;-)
> 
> 
> > +    else
> > +       # meson sets up ninja dist so we don't have to do worktrees and it
> > +       # has the builddir enabled by default
> IMHO using a worktree is good regardless if you're using meson or not:
>  - in provides fairly unique build destinations
>  - there's an explicit branch for each release, or attempted release

tbh, that's one of the more annoying things because my repos are littered
with branches that take several commands to remove (rm + worktree prune +
git branch -d). given that we only allow releasing tagged commits, I'm not
sure a branch (especially one with a random name) is needed.

meson could be set up to use a temporary name as builddir, that way you get
the directory structure of build.123xyz.

> > +       build_dir="builddir"
> > +       meson $build_dir
> 
> One could use the following pattern for both autotools and meson
> 
> make_worktree() {
>     # as above/existing code does it
> }
> 
> setup_build_systems() {
>     src_dir=`pwd`
> 
>     if meson
>         CONFIGURE="meson $src_dir"
>         MAKE=ninja
>         // toggles= ...?
>     if autotools
>         CONFIGURE="$src_dir/autogen.sh"
>         MAKE=make // seems to be handled elsewhere, move/consolidate here
>         // toggles= ...?
> }
> 
> // error handling and information logging omitted for brevity
> build_and_test() {
>     mkdir $build_dir && cd $build_dir
>     $CONFIGURE $src_dir $toggles
>     $MAKE $MAKE_DIST_CMD
> }

right, but that's a lot of work esp. with testing and I'm not sure 
I'll find the time for that.

> 
> > +       if [ $? -ne 0 ]; then
> > +           echo "Error: failed to configure module."
> > +           cd $top_src
> > +           return 1
> > +       fi
> > +
> > +       echo "Info: running \"ninja dist\" to create tarballs:"
> > +       ninja -C $build_dir dist
> 
> I heard that meson does not have distcheck, is that right?
> Should a warning "distcheck is not supported" be in order?

meson does distcheck as part of dist now. There is no specific distcheck
target though.

> How does one handle the following, ideally in a single go:
>  - running the tests
>  - ensuring that everything is installed and uninstalled properly
>  - checking the tarball contents are sufficient to create new tarball
> 
> Speaking of tarballs:
> Last I've looked meson relied on the project living in git/$vcs,
> otherwise a tarball could not be created.
> That doesn't sound like a robust solution, but I doubt this is the
> right place to ask for this.

looking at the git commit log, meson supports at least git and hg for dist.
I don't think we need to care about anything else for our release script?
Relying on git to create the tarball seems like the most robust solution to
me. After all, if it's not in git it doesn't exist. Generated files are
either generated from the tree or need to be checked in.

What meson does can be read here:
https://github.com/mesonbuild/meson/blob/master/mesonbuild/scripts/dist.py
for git it's basically:
  mkdir and cd into meson-dist
  git clone source tree (including submodules)
  git archive into a tarball
  run ninja test on that tarball
  clean up after ourselves

Which is also why the worktree approach isn't needed for meson because it
does a fresh git clone for every dist.

> > +       if [ $? -ne 0 ]; then
> > +           echo "Error: ninja dist failed"
> > +           cd $top_src
> > +           return 1
> > +       fi
> > +
> > +       # Find out the package name from the meson.build file
> > +       pkg_name=`$GREP '^project(' meson.build | sed "s|project([\'\"]\([^\'\"]\+\)[\'\"].*|\1|"`
> > +       pkg_version=`git describe`
> Isn't the version stored in project_version()?

well, yeah, but we're not in meson here. How would I get to that other than
grep?

> > @@ -721,7 +762,9 @@ process_module() {
> >      else
> >         tag_range=$tag_name
> >      fi
> > +    pushd "$tar_root"
> >      generate_announce > "$tar_name.announce"
> > +    popd
> With the above generalised suggestion the pushd/popd should not be needed.

the pushd is needed because meson puts the tarball in a specific directory.
I don't think that's configurable. md5sum etc. add the full path to the
output so we either need to hop into that directory or strip the paths out
later. push was the easier solution here.

Cheers,
   Peter