[libvirt] [PATCH v2 2/2] travis: convert ubuntu, centos & mingw builds to use new make rules

[Andrea Bolognani]

On Fri, 2019-03-15 at 13:44 +0000, Daniel P. Berrangé wrote:
> On Fri, Mar 15, 2019 at 02:27:55PM +0100, Andrea Bolognani wrote:
> > On Wed, 2019-03-06 at 09:34 +0000, Daniel P. Berrangé wrote:
> > > +++ b/.travis.yml
> > > @@ -11,26 +11,30 @@ matrix:
> > >          - docker
> > >        env:
> > >          - IMAGE="ubuntu-18"
> > > -        - DISTCHECK_CONFIGURE_FLAGS="--with-init-script=systemd"
> > > -        - DOCKER_CMD="$LINUX_CMD"
> > > +        - MAKE_ARGS="syntax-check distcheck DISTCHECK_CONFIGURE_FLAGS=--with-init-script-systemd"
> > > +      script:
> > > +        - make -f tests/Makefile.ci.inc cibuild-$IMAGE  MAKE_ARGS="$MAKE_ARGS"
> > 
> > Having a separate 'script' for each job in the matrix defeats the
> > purpose of setting values in the environment.
> 
> This could be written just using the script: entry without any
> env vars, but the env vars have the useful property that they
> are displayed in the build result page. So you can see the
> difference in each matrix entry at a glance.

Agreed, that's why I didn't suggest touching the environment :)

> > I would drop MINGW_CMD, change the existing LINUX_CMD to
> > 
> >   env:
> >     global:
> >       - LINUX_CMD='
> >           if test "$MINGW"; then
> >             make -f tests/Makefile.ci.inc "cibuild-$IMAGE" MAKE_ARGS="$MAKE_ARGS" CONFIGURE="$MINGW-configure";
> >           else
> >             make -f tests/Makefile.ci.inc "cibuild-$IMAGE" MAKE_ARGS="$MAKE_ARGS";
> >           fi
> >         '
> > 
> > and the existing default script to
> > 
> >   script:
> >     - /bin/sh -xc "$LINUX_CMD"
> 
> I really don't like having so many levels of indirection in the
> commands. It gets painful to understand, especially when you
> consider the shell quoting & escaping needs.
> 
> I'd rather have duplication of the "script" entry that is easy
> to understand.

Then go for the second suggestion, which you snipped in your reply:

> > Alternatively, you can drop all _CMD variables, including MACOS_CMD,
> > and put the shell code right into the 'script' directives, but doing
> > so would mean losing the tracing feature which can be useful to track
> > down build issues...

Doing so would remove the indirection, even for macOS builds, while
still avoiding duplicated script directives.

-- 
Andrea Bolognani / Red Hat / Virtualization