[pacman-dev] [RFC] makepkg: allow make-style environment var overrides

[Dave Reisner]

On Tue, Jul 23, 2013 at 06:57:07PM +0100, Ashley Whetter wrote:
> On 23 July 2013 18:18, Dave Reisner <dreisner at archlinux.org> wrote:
> 
> > Signed-off-by: Dave Reisner <dreisner at archlinux.org>
> > ---
> > Curious if folks think this is useful -- can definitely see myself using
> > this
> > now and then. It's different than prefixing makepkg with variables because
> > of
> > the order of evaluation. Prefixed vars are still subject to being
> > overriden by
> > config files because said file are sourced after the environment is parsed.
> > This patch adds the variables as late as possible to give them the best
> > chance
> > in life of taking effect.
> >
> >  scripts/makepkg.sh.in | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
> > index 06f7c25..0cf55a4 100644
> > --- a/scripts/makepkg.sh.in
> > +++ b/scripts/makepkg.sh.in
> > @@ -2624,6 +2624,15 @@ while true; do
> >         shift
> >  done
> >
> > +# attempt to parse any extra args (after the end-of-options delimiter) as
> > +# environment vars.
> > +while [[ $1 ]]; do
> > +       if [[ $1 = ?(_[[:alpha:]])+([[:alnum:]_])=* ]]; then
> > +               extra_env_vars+=("$1")
> > +       fi
> > +       shift
> > +done
> > +
> >  # setup signal traps
> >  trap 'clean_up' 0
> >  for signal in TERM HUP QUIT; do
> > @@ -2706,6 +2715,11 @@ if [[ ! -w $BUILDDIR ]]; then
> >         exit 1
> >  fi
> >
> > +# override settings from extra variables on commandline, if any
> > +if (( ${#extra_env_vars[*]} )); then
> > +       declare -x "${extra_env_vars[@]}"
> > +fi
> > +
> >  PKGDEST=${_PKGDEST:-$PKGDEST}
> >  PKGDEST=${PKGDEST:-$startdir} #default to $startdir if undefined
> >  if (( ! (NOBUILD || GENINTEG) )) && [[ ! -w $PKGDEST ]]; then
> > --
> > 1.8.3.3
> >
> >
> >
> Once I get around to starting the test suite for makepkg I hope to have
> some sort of way of overriding environment variables because it's obviously
> going to be useful for testing.

Why would this be useful for testing? If you need to control environment
for wider testing, inject your own with --config <file>. Note that
you're going to actually need to intercept calls to '.' or 'source'
because you can't guarantee that files will exist properly, etc etc...

If you need to control environment for smaller tests which only cover 1
to a few functions, then you're just setting vars in your test before
calling the makepkg code...