Re: yaccvpath.test
>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: [...] Pavel> I understand that your test case was to demonstrate the Pavel> first problem. But then "make distcheck" is irrelevant - Pavel> the problem can be detected already after "make distdir" Yes! [...] Pavel> However, please comment your test next time, otherwise Pavel> it takes too much time to understand what you meant to Pavel> test if something goes wrong. Actually most of your questions and comments in this thread suggest that you missed the start of the story: http://sources.redhat.com/ml/automake/2001-02/msg00561.html Pavel> And also please make some "unit testing" of your Pavel> tests. For example, YACC=bison Please stop reproaching this to me, or grep my submission for `YACC' before. We don't care who did that, all we want is to get it fixed; you did a great job in debugging that test case, but writing sentences like `another lame error in the few lines of the damned test' simply doesn't help. I know of nobody who is happy to discover he has introduced a bug, you don't need qualify it with rude words. [...] Thanks for the cleanup anyway, that's the most important. -- Alexandre Duret-Lutz
Re: yaccvpath.test
Pavel> I like you approach to do "what the user wants", I just don't Pavel> see a situation where anybody would want to create a file in Pavel> builddir instead of overwriting it in srcdir (or attempting to Pavel> do so with a subsequent failure). I agree. However, suppose the developer never puts parse.c into the srcdir. Then the current rules will continue to generate it in the build directory. Only after unpacking the distribution will it appear in srcdir. So it isn't a question of overwriting the file. The current code ought to overwrite the file if it already appears in srcdir, and it ought to put it in builddir if it doesn't appear in srcdir. Apparently in the latter case we fail to remove it from builddir during distclean. There's a good argument that we should simply disallow this though. First, it is complicated and confusing. Second, it is hard to make it work properly when building in srcdir. Tom
Re: yaccvpath.test
Hello, Tom!
Thank you for your answers! When I asked them I didn't realize that the
point of yaccvpath.test was not failed "make distcheck", but an
out-of-date file appearing in the tarball.
Anyway, I'm glad to see that our views are very similar.
> Pavel> 1) "make dist" must ensure that out-of-date generated
> Pavel> distributable files (parser.c, Makefile.in etc) are not
> Pavel> included in the tarball either by running "make all" or
> Pavel> otherwise. Yes or no?
>
> Yes. This has been on the to-do list for a long time.
> I don't recall what has been holding it up.
I do misuse this shortcut ("make dist" before "make all") but I know what
I'm doing, which may not be the case for other people. I'm ready to accept
some personal inconvenience in exchange for the better quality of software
using Automake :-)
> Pavel> 2) "make distcheck" must ensure that out-of-date generated
> Pavel> distributable files are not included in the tarball by exiting
> Pavel> with non-zero code. Yes or no?
>
> It would be nice but this is probably very hard, since the user can
> add random targets to build just about anything.
This is reasonable since you answer "yes" to the first question. "make
all" should guarantee it and "make dist" should rely on it.
> Pavel> 3) Out-of-date generated distributable files should be
> Pavel> recreated in the build directory. Always, never, only when no
> Pavel> write permissions for srcdir?
...
> For yacc/lex output the answer probably depends on what the user wants
> to happen. For instance you might have one answer for the developer
> and another answer after unpacking a `dist' tarball.
If we need it with the `dist' tarball it's a big problem with that
tarball. I won't mind a failure at this point.
I like you approach to do "what the user wants", I just don't see a
situation where anybody would want to create a file in builddir instead of
overwriting it in srcdir (or attempting to do so with a subsequent
failure).
> Pavel> 4) "make distclean" should attempt to clean generated
> Pavel> distributable files that appear in the build directory. Yes or
> Pavel> no?
>
> Yes. `make distclean' must leave the build directory as it was before
> configure. When `make distcheck' is failing in this test it is
> because distclean is not properly doing its job -- in a fresh build
> directory `configure ; make ; make distclean' must leave the directory
> empty.
I know what `make distclean' is supposed to do. Not creating distributable
files in the build directory would releave us from cleaning them there.
Regards,
Pavel Roskin
Re: yaccvpath.test
Pavel> 1) "make dist" must ensure that out-of-date generated Pavel> distributable files (parser.c, Makefile.in etc) are not Pavel> included in the tarball either by running "make all" or Pavel> otherwise. Yes or no? Yes. This has been on the to-do list for a long time. I don't recall what has been holding it up. Pavel> 2) "make distcheck" must ensure that out-of-date generated Pavel> distributable files are not included in the tarball by exiting Pavel> with non-zero code. Yes or no? It would be nice but this is probably very hard, since the user can add random targets to build just about anything. Pavel> 3) Out-of-date generated distributable files should be Pavel> recreated in the build directory. Always, never, only when no Pavel> write permissions for srcdir? There's not a general answer to this. configure and Makefile.in, for example, must always be made in srcdir regardless of any settings. Other generated files might depend on the strictness setting. (I don't know if any currently do.) For yacc/lex output the answer probably depends on what the user wants to happen. For instance you might have one answer for the developer and another answer after unpacking a `dist' tarball. Pavel> 4) "make distclean" should attempt to clean generated Pavel> distributable files that appear in the build directory. Yes or Pavel> no? Yes. `make distclean' must leave the build directory as it was before configure. When `make distcheck' is failing in this test it is because distclean is not properly doing its job -- in a fresh build directory `configure ; make ; make distclean' must leave the directory empty. Tom
Re: yaccvpath.test
Pavel> I believe, the best fix will be to have tests/defs to copy the Pavel> right install-sh instead of creating an empty file. I agree. I have a patch for this which I'll check in once the test suite is done. Tom
Re: yaccvpath.test
Hello, Alexandre!
> Pavel> It's not Perl. It's a timestamp quantization.
>
> Oops, I should have read this mail before posting my own patch...
I'm applying my patch with few other changes. It appears that we have more
than one problem - one of them is that the old file is distributed and
another one it that "make distcheck" detects the problem quite late - when
it runs "make distclean".
I understand that your test case was to demonstrate the first problem. But
then "make distcheck" is irrelevant - the problem can be detected already
after "make distdir" - we don't even need gzip for that!
If you want to add a test for "make distcheck" you are welcome to.
However, please comment your test next time, otherwise it takes too much
time to understand what you meant to test if something goes wrong.
And also please make some "unit testing" of your tests. For example,
YACC=bison had no chances to work even when configuring in the source
tree, since bison outputs files with different names.
Regards,
Pavel Roskin
--- ChangeLog
+++ ChangeLog
@@ -1,3 +1,12 @@
+2001-02-27 Pavel Roskin <[EMAIL PROTECTED]>
+
+ * tests/yaccvpath.test: Add a delay to make parse.c really out
+ of date. Detect the problem earlier, after `make distdir'. Drop
+ dependency on flex. Always use the `-y' flag for bison. Comment
+ changes.
+
+ * tests/Makefile.am: Add yaccvpath.test to XFAIL_TESTS.
+
2001-03-02 Jens Krüger <[EMAIL PROTECTED]>
* depend2.am (?!GENERIC??LIBTOOL?%LTOBJ%): Add `%' to fix typo.
--- tests/Makefile.am
+++ tests/Makefile.am
@@ -2,7 +2,7 @@
AUTOMAKE_OPTIONS = gnits
-XFAIL_TESTS =
+XFAIL_TESTS = yaccvpath.test
TESTS =\
acinclude.test \
aclocal.test \
--- tests/yaccvpath.test
+++ tests/yaccvpath.test
@@ -1,12 +1,19 @@
#! /bin/sh
-# This attempts to `make distcheck' from a separate directory
-# (i.e. builddir!=srcdir). Before doing `make distcheck' a parser
-# definition is updated in the srcdir in order to check whether the
-# archived perser is up-to-date or not.
+# This test checks that dependent files are updated before including
+# in the distribution. `parse.c' depends on `parce.y'. The later is
+# updated so that `parse.c' should be rebuild. Then we are running
+# `make' and `make distdir' and check whether the version of `parse.c'
+# to be distributed is up to date.
. $srcdir/defs || exit 1
+# Fail gracefully if no autoconf.
+$needs_autoconf
+# Likewise for some other tools.
+(gcc -v) > /dev/null 2>&1 || exit 77
+(bison -V) > /dev/null 2>&1 || exit 77
+
cat > configure.in << 'END'
AC_INIT
AC_CONFIG_AUX_DIR([.])
@@ -19,10 +26,11 @@
END
cat > Makefile.am << 'END'
-bin_PROGRAMS= foo
-foo_SOURCES= parse.y foo.c
+bin_PROGRAMS = foo
+foo_SOURCES = parse.y foo.c
END
+# Original parser, with `foobar'
cat > parse.y << 'END'
%{
int yylex () {return 0;}
@@ -36,16 +44,8 @@
int main () { return 0; }
END
-# Fail gracefully if no autoconf.
-$needs_autoconf
-# Likewise for some other tools.
-(gcc -v) > /dev/null 2>&1 || exit 77
-(flex -V) > /dev/null 2>&1 || exit 77
-(bison -V) > /dev/null 2>&1 || exit 77
-
-LEX=flex
-export LEX
-YACC=bison
+# We are not checking Autoconf, so we pick $YACC for it.
+YACC="bison -y"
export YACC
# Remove some files installed by defs.
@@ -58,15 +58,27 @@
$AUTOCONF
$AUTOMAKE -a
-bison -y parse.y
+$YACC parse.y
mv y.tab.c parse.c
-cat >> parse.y << 'END'
-fubar : 'f' foobar {};
-END
-
mkdir sub
cd sub
../configure
+
+# A delay is needed to make sure that the new parse.y is indeed newer
+# than parse.c, i.e. the they don't have the same timestamp.
+sleep 2
+
+# New parser, with `fubar'
+cat > parse.y << 'END'
+%{
+int yylex () {return 0;}
+void yyerror (char *s) {}
+%}
+%%
+fubar : 'f' 'o' 'o' 'b' 'a' 'r' {};
+END
+
$MAKE
-$MAKE distcheck
+$MAKE distdir
+grep fubar foo-0.1/parse.c
Re: yaccvpath.test
Alexandre Oliva wrote:
> On Feb 28, 2001, "Derek R. Price" <[EMAIL PROTECTED]> wrote:
>
> > CVS uses a single second sleep to guarentee timestamps change cross-platform
>
> IIRC, FAT filesystems can only store even second numbers. So, in
> order to be 100% safe, you'd need to sleep for 2 seconds, but a
> 1-second sleep should be ok on at least 50% of the cases.
I don't think so. The CVS code does the following, regardless of the platform:
while (last_register_time && time ((time_t *) NULL) == last_register_time)
{
* sleep 20ms *
}
Where last_register_time is the last time a file was written (recorded just after
writing).
In other words, this code simply waits until the next second. I don't usually
work on the Windows specific code myself, but everything here except the sleep
function is common code, and unless the clock and not just the file system has a
2 second granularity, then a race condition would have been created. I haven't
seen the bug reports and I know for a fact that the Windows sleep function was
just recently rewritten to allow millisecond granularity, so the rest is
doubtful.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
I will not celebrate meaningless milestones.
I will not celebrate meaningless milestones.
I will not celebrate meaningless milestones...
- Bart Simpson on chalkboard, _The Simpsons_
Re: yaccvpath.test
On Feb 28, 2001, "Derek R. Price" <[EMAIL PROTECTED]> wrote:
> CVS uses a single second sleep to guarentee timestamps change cross-platform
IIRC, FAT filesystems can only store even second numbers. So, in
order to be 100% safe, you'd need to sleep for 2 seconds, but a
1-second sleep should be ok on at least 50% of the cases.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: yaccvpath.test
Hello, Derek! > > Some unices (including GNU/Linux) are not very precise with respect to the > > timestamps. It's likely that parse.c and the new parse.y are created in > > the same second, so parse.c will appear to be up-to-date. Adding "sleep > > 3" (I have no idea what would be a minimal safe time) before the new > > CVS uses a single second sleep to guarentee timestamps change cross-platform > and we don't see bug reports about it. Only ocassionaly complaints that > scripts which invoke CVS many times take too long. Thanks! Then "touch parse.y" can be moved below "configure", since the later is guaranteed to take at least 1 second (see AM_SANITY_CHECK). Regards, Pavel Roskin
Re: yaccvpath.test
Pavel Roskin wrote: > Some unices (including GNU/Linux) are not very precise with respect to the > timestamps. It's likely that parse.c and the new parse.y are created in > the same second, so parse.c will appear to be up-to-date. Adding "sleep > 3" (I have no idea what would be a minimal safe time) before the new CVS uses a single second sleep to guarentee timestamps change cross-platform and we don't see bug reports about it. Only ocassionaly complaints that scripts which invoke CVS many times take too long. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- "A slipping gear could let your M203 grenade launcher fire when you least expect it. That would make you quite unpopular in what's left of your unit." -- In the August 1993 issue, page 9, of PS magazine, the Army's magazine of preventive maintenance
Re: yaccvpath.test
Hello, Alexandre! I'm applying my patch, Ok? > Pavel> Now we have a more interesting error: > > This is *the* error this test is expected to show. Thanks :) The only question remains, whether it's a bug a not. I'm affraid it's a highly debatable topic. I think it's Ok to test for features if there is consensus that it's features and not bugs and vice versa. So I'll outline some questions. If we argee on them - fine, if not, let's not enforce arguments with test cases. 1) "make dist" must ensure that out-of-date generated distributable files (parser.c, Makefile.in etc) are not included in the tarball either by running "make all" or otherwise. Yes or no? 2) "make distcheck" must ensure that out-of-date generated distributable files are not included in the tarball by exiting with non-zero code. Yes or no? 3) Out-of-date generated distributable files should be recreated in the build directory. Always, never, only when no write permissions for srcdir? 4) "make distclean" should attempt to clean generated distributable files that appear in the build directory. Yes or no? Regards, Pavel Roskin
Re: yaccvpath.test
>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: Pavel> Hello, Alexandre! Pavel> It fails on RedHat 6.2, but not 7.0. I believe it's a Pavel> Perl issue. Not sure if I'll have time today to look at Pavel> this. Pavel> It's not Perl. It's a timestamp quantization. Oops, I should have read this mail before posting my own patch... [...] Pavel> Now we have a more interesting error: This is *the* error this test is expected to show. Thanks :) Pavel> make[3]: Leaving directory Pavel> `/usr/local/src/am1/tests/testSubDir/sub/foo-0.1/=build' Pavel> Error: files left after distclean Pavel> make[2]: *** [distcheck] Error 1 Pavel> make[2]: Leaving directory `/usr/local/src/am1/tests/testSubDir/sub' Pavel> FAIL: yaccvpath.test Pavel> The file left after distclean is parse.c in the "=build" directory. [...] -- Alexandre Duret-Lutz
Re: yaccvpath.test
>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: Pavel> Hello, Alexandre! >> >> Alexandre claims it fails. >> >> Yes it should. Pavel> Then show us how it fails. You did it in the next mail. [...] Pavel> But I don't see that your are testing for that Pavel> problem. Your test is quite generic - "make distcheck" Pavel> should pass. No it dows stop because a newer parse.c is generated in the build tree (because the parse.c included in the distribution is not up to date w.r.t parse.y). [...] >> Isn't this a workaround to an Automake bug? It look so to me: >> if install-sh is in current directory, why would Automake prefer >> and use ../../install-sh? Pavel> It's a complicated mix of several bugs and ancient Pavel> traditions. I believe, the best fix will be to have Pavel> tests/defs to copy the right install-sh instead of Pavel> creating an empty file. yaccvpath already erase these files and run `automake -a'. -- Alexandre Duret-Lutz
Re: yaccvpath.test
>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>>>>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> I don't quite understand whether your test is supposed to work
Pavel> or not. It's failing for me (besides the typo in
Pavel> tests/Makefile.am that I've just fixed).
Tom> Alexandre claims it fails.
Tom> I've updated it a bit. Now it works for me.
Tom> Alexandre, can you investigate the change?
Tom> I changed it to only configure and build once.
Tom> Actually, sometimes bison complains when I run the test and sometimes
Tom> it does not. Weird.
Ok, I think I have fixed the testcase (I mean, it now fails succesfully :))
It seems it was a timestamp issue. First parse.y is create, then
parse.c is generated, (this takes less than a second since you removed
the first configure/make call); if parse.y is updated during this same
second, parse.c is considered up-to-date by make, and make distcheck
doesn't complain. I have fixed that in two ways:
- when parse.y is updated, add a string that can be grepped for
latter in parse.c; and grep for this string in the fresh
distribution made by make distcheck (make dist would be enough).
- add a sleep before updating parse.y
Actually grepping is not needed when `make distcheck' does its job
correctly, so if you think two checks for the same things are too much
you might want to remove the grep call, or replace `make distcheck' by
`make dist'.
2001-02-27 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* tests/yaccvpath.test: Check for no gzip; run bison in yacc mode;
sleep before updating parse.y to have a different timestamp;
append a comment to parse.y instead of adding an usused rule;
grep for that comment in the resulting parse.c from the distribution
in addition to running make distcheck.
--- tests/yaccvpath.test.oldTue Feb 27 20:18:29 2001
+++ tests/yaccvpath.testTue Feb 27 20:55:03 2001
@@ -42,10 +42,11 @@
(gcc -v) > /dev/null 2>&1 || exit 77
(flex -V) > /dev/null 2>&1 || exit 77
(bison -V) > /dev/null 2>&1 || exit 77
+(gzip -V) > /dev/null 2>&1 || exit 77
LEX=flex
export LEX
-YACC=bison
+YACC='bison -y'
export YACC
# Remove some files installed by defs.
@@ -58,11 +59,16 @@
$AUTOCONF
$AUTOMAKE -a
-bison -y parse.y
+$YACC parse.y
mv y.tab.c parse.c
+# sleep to make sure the timestamp of parse.y will be
+# different from the timestamp of parse.c when make distcheck run.
+sleep 2
+
cat >> parse.y << 'END'
-fubar : 'f' foobar {};
+%%
+/* GrepMe */
END
mkdir sub
@@ -70,3 +76,8 @@
../configure
$MAKE
$MAKE distcheck
+# distcheck should be king enough to detect if parse.c is up-to-date
+# in the distribution.
+# Below is another way to test for the same thing.
+gzip -d -c foo-0.1.tar.gz | tar xf -
+grep GrepMe foo-0.1/parse.c
[...]
--
Alexandre Duret-Lutz
Re: yaccvpath.test
Hello, Alexandre!
> Pavel> It fails on RedHat 6.2, but not 7.0. I believe it's a
> Pavel> Perl issue. Not sure if I'll have time today to look at
> Pavel> this.
It's not Perl. It's a timestamp quantization.
Some unices (including GNU/Linux) are not very precise with respect to the
timestamps. It's likely that parse.c and the new parse.y are created in
the same second, so parse.c will appear to be up-to-date. Adding "sleep
3" (I have no idea what would be a minimal safe time) before the new
parse.y is created makes the test fail reliably:
make[2]: Entering directory `/usr/local/src/am1/tests/testSubDir/sub'
bison ../parse.y && mv y.tab.c parse.c
../parse.y contains 1 useless nonterminal and 1 useless rule
mv: y.tab.c: No such file or directory
make[2]: *** [parse.c] Error 1
Well, another lame error in the few lines of the damned test! Setting
YACC=bison is absolutely wrong! It's not going to work this way. Bison
creates files with different names by default. If we really don't trust
Autoconf to find YACC (probably we shouldn't, since we are testing not
Autoconf), let's use YACC="bison -y".
By the way, I don't understand why we need LEX. It's absolutely irrelevant
to the test.
Now we have a more interesting error:
make[3]: Leaving directory
`/usr/local/src/am1/tests/testSubDir/sub/foo-0.1/=build'
Error: files left after distclean
make[2]: *** [distcheck] Error 1
make[2]: Leaving directory `/usr/local/src/am1/tests/testSubDir/sub'
FAIL: yaccvpath.test
The file left after distclean is parse.c in the "=build" directory.
Just for reference, here's the patch I applied to yaccvpath.test
--- yaccvpath.test
+++ yaccvpath.test
@@ -40,12 +40,9 @@
$needs_autoconf
# Likewise for some other tools.
(gcc -v) > /dev/null 2>&1 || exit 77
-(flex -V) > /dev/null 2>&1 || exit 77
(bison -V) > /dev/null 2>&1 || exit 77
-LEX=flex
-export LEX
-YACC=bison
+YACC="bison -y"
export YACC
# Remove some files installed by defs.
@@ -61,6 +58,7 @@
bison -y parse.y
mv y.tab.c parse.c
+sleep 3
cat >> parse.y << 'END'
fubar : 'f' foobar {};
END
Regards,
Pavel Roskin
Re: yaccvpath.test
Hello, Alexandre! > >> Alexandre claims it fails. > > Yes it should. Then show us how it fails. > Perl? I guess you have found *another* issue :) What I'm trying We'll see when I get home. > to report is just a Makefile issue: $scrdir/parser.c is included > in the distribution insted of ./parser.c. In fact, I believe that you are wrongly assuming this to be a bug. Files that are distributed should be in srcdir. But I don't see that your are testing for that problem. Your test is quite generic - "make distcheck" should pass. Do you expect that one of the version of parse.y is invalid? > >> I always build in a separate directory, never in srcdir. > > Pavel> It should be irrelevant now after since I've added > Pavel> AC_CONFIG_AUX_DIR. > > Isn't this a workaround to an Automake bug? It look so to me: > if install-sh is in current directory, why would Automake prefer > and use ../../install-sh? It's a complicated mix of several bugs and ancient traditions. I believe, the best fix will be to have tests/defs to copy the right install-sh instead of creating an empty file. Regards, Pavel Roskin
Re: yaccvpath.test
>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: Pavel> Hello, Tom and Alexandre! Pavel> On 27 Feb 2001, Tom Tromey wrote: [...] >> Alexandre claims it fails. Yes it should. >> I've updated it a bit. Now it works for me. >> Alexandre, can you investigate the change? I will check it at home tonight (bison here is broken since the lattest Debian upgrade). I'll also try the cross-install-strip change. Pavel> It fails on RedHat 6.2, but not 7.0. I believe it's a Pavel> Perl issue. Not sure if I'll have time today to look at Pavel> this. Perl? I guess you have found *another* issue :) What I'm trying to report is just a Makefile issue: $scrdir/parser.c is included in the distribution insted of ./parser.c. >> I always build in a separate directory, never in srcdir. Pavel> It should be irrelevant now after since I've added Pavel> AC_CONFIG_AUX_DIR. Isn't this a workaround to an Automake bug? It look so to me: if install-sh is in current directory, why would Automake prefer and use ../../install-sh? -- Alexandre Duret-Lutz
Re: yaccvpath.test
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: Pavel> It fails on RedHat 6.2, but not 7.0. I believe it's a Perl Pavel> issue. Not sure if I'll have time today to look at this. I'm running 6.2 and it works for me. Tom
Re: yaccvpath.test
Hello, Tom and Alexandre! On 27 Feb 2001, Tom Tromey wrote: > > "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: > > Pavel> I don't quite understand whether your test is supposed to work > Pavel> or not. It's failing for me (besides the typo in > Pavel> tests/Makefile.am that I've just fixed). > > Alexandre claims it fails. > I've updated it a bit. Now it works for me. > Alexandre, can you investigate the change? It fails on RedHat 6.2, but not 7.0. I believe it's a Perl issue. Not sure if I'll have time today to look at this. > I always build in a separate directory, never in srcdir. It should be irrelevant now after since I've added AC_CONFIG_AUX_DIR. Regards, Pavel Roskin
Re: yaccvpath.test
>>>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: Pavel> I don't quite understand whether your test is supposed to work Pavel> or not. It's failing for me (besides the typo in Pavel> tests/Makefile.am that I've just fixed). Alexandre claims it fails. I've updated it a bit. Now it works for me. Alexandre, can you investigate the change? I changed it to only configure and build once. Actually, sometimes bison complains when I run the test and sometimes it does not. Weird. Pavel> I believe there is a convention in Automake that whenever a Pavel> knowingly failing test is committed, it is added to Pavel> XFAIL_TESTS, and it's only removed from there when the fix is Pavel> committed. My fault. Pavel> Maybe you don't know, but yaccvpath.test fails very differently Pavel> when automake is configured in the source directory and outside Pavel> it. You probably should add AC_CONFIG_AUX_DIR(.) to the test Pavel> (see e.g. install2.test), unless I'm missing something. Interesting. Alexandre, how does it fail for you? I always build in a separate directory, never in srcdir. Pavel> Also please make sure that the test is ignored when bison and Pavel> yacc are not available. Done. Tom
yaccvpath.test
Hello, Alexandre! I don't quite understand whether your test is supposed to work or not. It's failing for me (besides the typo in tests/Makefile.am that I've just fixed). I believe there is a convention in Automake that whenever a knowingly failing test is committed, it is added to XFAIL_TESTS, and it's only removed from there when the fix is committed. Maybe you don't know, but yaccvpath.test fails very differently when automake is configured in the source directory and outside it. You probably should add AC_CONFIG_AUX_DIR(.) to the test (see e.g. install2.test), unless I'm missing something. Also please make sure that the test is ignored when bison and yacc are not available. Regards, Pavel Roskin
