Re: pre-inst-guile

[Rob Browning]

Thien-Thi Nguyen <address@hidden> writes:

> thanks for motivating me to do this eminently sensible change!

This is nice.  Thanks.

The only (minor) other advantage I can see to having the
pre-inst-guile script generated by a Makefile.am target from a .in
file rather than generated at configure time is that when you're
developing, if you edit the .in file, you automagically get an
immediate update to the resulting script the next time you "make".
When things are generated by configure, you'll have to remember to
re-run configure if you make any changes to the source fragments.
Whether or not we really care about that, I don't know...

However, on a related note, I was working on some fixes we need in
guile-config.in, and I wanted to add some tests of guile-config itself
so we'll catch any breakage in the future, but I ran in to two issues:

  1) How do we want to handle tests that run shell scripts,
     i.e. non-scheme code tests?  I can just add a TESTS = a b c to
     test-suite/Makefile.am and automake will handle running them, but
     wasn't sure that was sufficient to our needs.

  2) How do we want to handle trying to run guile-config from the
     build tree during make check?  In a couple of other projects I
     could handle it like this, but I don't think guile has anything
     equivalent yet:

     In gnucash:

         PATH=${top_srcdir}/src/bin/test/overrides:${PATH}
         gnucash --something-to-test

       or

         PATH=${top_srcdir}/src/bin/test/overrides:${PATH}
         gnucash-env some-gnucash-cmd --something-to-test
         
     In another-project:

         The -st below stands for "source tree".  There are both -st
         and non -st versions of all the bin/ files in the source
         tree.  For each bin/ file, there's a .in file which is used
         to generate both the -st and non-st versions of the command
         based on different "sed" substitutions.

           ${top_srcdir}/src/bin/some-program-st --something-to-test

Not sure we care about following either of these approaches -- I'm
just presenting them as prior art -- but I would like for us to have
similar functionality -- the ability to run all our top level scripts
from the build tree so we can test everything we're eventually going
to install in bin/ during make check.

Thoughts?

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