Re: pre-inst-guile

[Rob Browning]

Thien-Thi Nguyen <address@hidden> writes:

> yes, this is sufficient, and probably the best way to go about it.
> supporting shell script tests opens the door for all other test classes
> that currently cannot be supported by the scheme-code-only restriction.
> it would be wise to have "aliveness" tests implemented in sh.

Yep.  To start with I just want guile --version and some guile-config
things tested, but eventually I'd like to have much more tested.

> guile-config's invocation uses "guile -e main -s", so we can use:
>
> ./pre-inst-guile -e main -s guile-config/guile-config
>
> if we can't, that's a bug in pre-inst-guile, since it's supposed to be
> drop-in replaceable.  (i've verified that this works here, btw.)

OK, that seems pretty good for this case, though it wouldn't handle a
script that has sub-invocations of guile.  I suppose we can cross that
bridge when (if) we come to it :>

Come to think of it, we could probably cross that bridge just fine by
doing something like this during make check (or make):

  cd test-suite
  mkdir test-bins
  cd test-bins
  ln -s ${top_srcdir}/pre-inst-guile ./guile
  PATH=`pwd`:${PATH} ./guile -e main -s ${top_srcdir}/some/script-to-test

basically linking pre-inst-guile as guile in some temp dir and putting
that dir first in the path.  Then even sub-execs of guile (as long as
they weren't fully qualified) would work fine.  Of course that leaves
unanswered the question of how often they wouldn't be fully
qualified. sub #! guile scripts would still fail.

However if we switched our scripts to use

  #!/usr/bin/env guile

we'd be fine, which is how the new SRFI wants you to invoke other
things, but I'm not what if any issues there might be regarding the
use of env in general...

FWIW

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD