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

[Emil Velikov]

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


> +       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
}

> +       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?

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.

> +       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()?


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

Thanks
Emil