-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Santiago Vila pointed out that m4's conversion to GFDL 1.3 was incomplete;
and I made the mistake of copying-and-pasting m4's action over to
autoconf: http://git.sv.gnu.org/cgit/autoconf.git/commit/?id=a30e6f.
Pushing this.
- --
Don't work too hard,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 4/6/2009 11:14 AM:
probably need to teach more of autotest about automake's recent addition of
status 99 meaning hardfail (not even XFAIL can exempt it from making the
overall testsuite report failure), but that is why
On Mon, 13 Apr 2009, Thomas Moulard wrote:
On Sat, Apr 11, 2009 at 1:21 PM, Eric Blake e...@byu.net wrote:
This is very doable. In fact, it is how the m4 testsuite allows the user
to specify an alternate $SED program [1]. You can use atlocal.in to
perform initialization of your
On Monday 13 April 2009 06:03:05 Thomas Dickey wrote:
On Mon, 13 Apr 2009, Thomas Moulard wrote:
On Sat, Apr 11, 2009 at 1:21 PM, Eric Blake e...@byu.net wrote:
This is very doable. In fact, it is how the m4 testsuite allows the
user to specify an alternate $SED program [1]. You can use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Mike Frysinger on 4/13/2009 4:40 AM:
I just had to use which to force an absolute path as Valgrind does not
which probably isn't guaranteed to appear on every platform that
autoconf scripts might run on - ymmv
nor is it guaranteed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Thomas Moulard on 4/12/2009 8:01 PM:
However, I still have an issue with the other scenario (MinGW
cross-compiling):
in that case, my binaries are suffixed with '.exe'.
Is is easy to make Autotest aware of EXEEXT, however AT_TESTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Thomas Moulard on 4/13/2009 6:00 AM:
About the which issue, Valgrind does not need an absolute path, it is just
that I used to rely on the fact that my binaries are always in my PATH.
autotest can be made to guarantee that the binary
