Re: yaccvpath.test

2001-03-05 Thread Alexandre Duret-Lutz

 "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

2001-03-03 Thread Tom Tromey

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

2001-03-03 Thread Tom Tromey

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

2001-03-02 Thread Derek R. Price

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

2001-03-02 Thread Pavel Roskin

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 21 || exit 77
+(bison -V)  /dev/null 21 || 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 21 || exit 77
-(flex -V)  /dev/null 21 || exit 77
-(bison -V)  /dev/null 21 || 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

2001-03-01 Thread Alexandre Oliva

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

2001-02-28 Thread Alexandre Duret-Lutz

 "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 21 || exit 77
 (flex -V)  /dev/null 21 || exit 77
 (bison -V)  /dev/null 21 || exit 77
+(gzip -V)  /dev/null 21 || 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

2001-02-28 Thread Alexandre Duret-Lutz

 "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

2001-02-28 Thread Pavel Roskin

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

2001-02-28 Thread Derek R. Price

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

2001-02-27 Thread Pavel Roskin

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

2001-02-27 Thread Pavel Roskin

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 21 || exit 77
-(flex -V)  /dev/null 21 || exit 77
 (bison -V)  /dev/null 21 || 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





yaccvpath.test

2001-02-26 Thread Pavel Roskin

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





Re: yaccvpath.test

2001-02-26 Thread Tom Tromey

 "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