Re: Five bugs in Vala integration

[Ralf Wildenhues]

* Valentin David wrote on Wed, Sep 08, 2010 at 12:23:27AM CEST:
> But if you want to say what your position is about
> not shipping derived source, I would appreciate. I have no idea if
> there are arguments for shipping them.

Well, are the derived sources portable, i.e., not depending on the
system on which they are created?  Is it useful to be able to build
a package tarball without having Vala installed?  Also, do the derived
sources vary heavily (and incompatibly) between Vala versions they were
created from, to the extent that it is not useful to set a fixed Vala
version by the package creator?

Automake ships derived sources for tools that are not expected to be
installed on the system used for compiling from a tarball.  The question
boils down to whether this is a desirable and/or viable goal.

Thanks,
Ralf

Re: verbosity of test failure feedback

[Ralf Wildenhues]

* Stefano Lattarini wrote on Wed, Sep 08, 2010 at 12:36:05AM CEST:
> What about creating a separeted tarball for any failed/skipped test
> (maybe in a proper common subdirectory `tests/test-suite.dir'), then
> displaiyng a message which tells the user "detailed information about
> tests' failures are available in files saved in `tests/test-suite.dir';
> please copy this directory to a safe known place, and write to the
> mailing list  for more information regarding
> how to send these information over to package maintainers"?

Well, as a general rule I think users should keep around their build
directories (unchanged) while issues are being hashed out.  This is
nothing that is specific to Automake though.  :-)

If you have to ask one more time for more details anyway, you might as
well make that as specific as possible and ask only for that which is
missing.  The only viable alternative I see for avoiding the extra round
trip is getting users to upload such tarballs to a binary post site, of
which I don't know any specifically free ones, so I'm not sure promoting
such is a good idea for a GNU package.

Cheers,
Ralf

Re: verbosity of test failure feedback (was: Automake 1.11.1 glitch?)

[Stefano Lattarini]

On Wednesday 08 September 2010, Bob Friesenhahn wrote:
> On Tue, 7 Sep 2010, Ralf Wildenhues wrote:
> > Actually, I haven't come across many test failures where more
> > information was necessary.  At least in this case I think it was
> > crystal clear from the silent5.log file, no?  ;-)
> > 
> > One practical problem with sending test directory contents by
> > default is that they can be pretty large.  When multiple
> > failures occur, say, all Libtool-related tests fail due to a
> > Libtool installation bug, we're speaking of several MB packed. 
> > I don't really want this sent to a public mailing list read by
> > dozens of people.
> 
> Yes, and as a point of fact, my message was rejected by the mailing
> list and only made it to Stefano due to being listed in the Cc:.
Ouch.  You are right, unfortunately.

What about creating a separeted tarball for any failed/skipped test
(maybe in a proper common subdirectory `tests/test-suite.dir'), then
displaiyng a message which tells the user "detailed information about
tests' failures are available in files saved in `tests/test-suite.dir';
please copy this directory to a safe known place, and write to the
mailing list  for more information regarding
how to send these information over to package maintainers"?

Would that help IYO (In Your Opinion)?

Regards,
  Stefano

Re: verbosity of test failure feedback (was: Automake 1.11.1 glitch?)

[Stefano Lattarini]

On Tuesday 07 September 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Tue, Sep 07, 2010 at 06:00:04PM CEST:
> > Darn, I've been sloppy: I should have also asked you to provide
> > us with the (tarred) content of the temporary test directory
> > `tests/silent5.dir'.  Could you kindly send this over to the list
> > too?
> > 
> > ( to self and to Ralf: it would be nice if the Automake
> > testsuite could create, whenever a failure occurs, a tarball
> > containg all the relevant logs and the contents of all relevant
> > temporary test directories, to avoid plaguing the poor bug
> > reporters with continuos requests of more details )
> 
> Actually, I haven't come across many test failures where more
> information was necessary.  At least in this case I think it was
> crystal clear from the silent5.log file, no?  ;-)
Only if you are smarter than me (which you probably are ;-)

> One practical problem with sending test directory contents by
> default is that they can be pretty large.
True enough; see my answer to Bob follow-up message.

> When multiple failures occur, say, all Libtool-related tests fail
> due to a Libtool installation bug, we're speaking of several MB
> packed.  I don't really want this sent to a public mailing list
> read by dozens of people.
Agreed; see my answer to Bob follow-up message.
 
Regards,
   Stefano

Re: Five bugs in Vala integration

[Valentin David]

On Tue, Sep 7, 2010 at 11:10 PM, Ralf Wildenhues  wrote:
> We've had two proposed Vala patches in the last year or so, and had to
> drop both because the copyright question could not be cleared.  So if
> (and when) that is cleared for you, I'd be glad to review patches from
> you to improve things here.

I will probably try to fix them when I get the paperwork done.

> If you'd like me to comment on the reported bugs in detail before that,
> please ping me.

Not about the bugs. But if you want to say what your position is about
not shipping derived source, I would appreciate. I have no idea if
there are arguments for shipping them.

-- 
Valentin David
valentin.da...@gmail.com

Re: verbosity of test failure feedback (was: Automake 1.11.1 glitch?)

[Bob Friesenhahn]

On Tue, 7 Sep 2010, Ralf Wildenhues wrote:


Actually, I haven't come across many test failures where more
information was necessary.  At least in this case I think it was
crystal clear from the silent5.log file, no?  ;-)

One practical problem with sending test directory contents by default
is that they can be pretty large.  When multiple failures occur, say,
all Libtool-related tests fail due to a Libtool installation bug, we're
speaking of several MB packed.  I don't really want this sent to a
public mailing list read by dozens of people.


Yes, and as a point of fact, my message was rejected by the mailing 
list and only made it to Stefano due to being listed in the Cc:.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: Five bugs in Vala integration

[Ralf Wildenhues]

Hello Valentin,

* Valentin David wrote on Tue, Sep 07, 2010 at 07:02:09PM CEST:
> I looked at how Vala was integrated into Automake, and it seemed to me
> that it was very fishy.

Yes, I agree.  Improving that would be very nice, even only providing
failing test cases would be good.

We've had two proposed Vala patches in the last year or so, and had to
drop both because the copyright question could not be cleared.  So if
(and when) that is cleared for you, I'd be glad to review patches from
you to improve things here.

If you'd like me to comment on the reported bugs in detail before that,
please ping me.

Thanks,
Ralf

Five bugs in Vala integration

[Valentin David]

Hello bug-automake,

I looked at how Vala was integrated into Automake, and it seemed to me
that it was very fishy. Works nicely for a small programs. I tried to
make a program like Shotwell to use Automake. It is still a very small
project. But that was a failure just because the compilation scheme
had different flags and sources depending on the operating system. And
each time I tried a work-around, I got stuck onto another bug. At the
end I did not succeed. Here are some test cases that illustrate the
problems (all of them should fail on both the master branch and in the
1.11 release):

First bug. configure.ac:
AC_INIT
AM_INIT_AUTOMAKE(nonesuch, nonesuch)
AM_PROG_VALAC
AC_PROG_CC
AC_OUTPUT(Makefile)

And Makefile.am:
bin_PROGRAMS=a b
a_SOURCES=a.vala
b_SOURCES=a.vala

This one produces two rules for $(srcdir)/a.c. Make will complain about it.
Makefile:283: warning: overriding commands for target `a.c'
Makefile:275: warning: ignoring old commands for target `a.c'

It is also important to know that we might want different a_VALAFLAGS
and b_VALAFLAGS. This means that a.vala should produce a-a.c and b-a.c
in this case. The compilation in Vala depends on what other source are
includes. So it means that:
a_SOURCES=a.vala c.vala
b_SOURCES=a.vala b.vala
with the same _VALAFLAGS might still generate, I believe, different
a.c due to the fact that c.vala and b.vala might define two different
environments used by a.vala. Though this is to check with the
specifications of Vala. But I am not sure they ensure that the result
should be the same. Otherwise they would not require to have all the
modules as parameters and just translate file by file.

Second bug, configure.ac:
AC_INIT
AM_INIT_AUTOMAKE(nonesuch, nonesuch)
AM_PROG_VALAC
AC_PROG_CC
AM_CONDITIONAL([FOO], [(exit 1)])
AC_OUTPUT(Makefile)

Makefile.am:
bin_PROGRAMS=a
a_SOURCES=a.vala

if FOO
a_SOURCES+=b.vala
endif

In this one DIST_COMMON will have both a.c and b.c. However, both
rules for $(srcdir)/a.c and $(srcdir)/b.c will depend on a_vala.stamp.
However the rule for this last one will not build b.c because it will
use the sources in $(a_SOURCES). So "make dist" will simply fail.
Perhaps b.vala uses a package that is not on the machine it is built.
But still you want to be able to make the distribution. So it should
not fail.

Third bug, (considering that bug 2 is fixed) configure.ac:
AC_INIT
AM_INIT_AUTOMAKE(nonesuch, nonesuch)
AM_PROG_VALAC
AC_PROG_CC
AC_ARG_ENABLE([foo], AS_HELP_STRING([foo])], [foo=yes], [foo=no])
AM_CONDITIONAL([FOO], [test "${foo:-no}" = yes])
AC_OUTPUT(Makefile)

Makefile.am:
bin_PROGRAMS=a
a_SOURCES=a.vala

if FOO
a_VALAFLAGS=--pkg=something
else
a_VALAFLAGS=--pkg=someotherthing
endif

Try to compile with --disable-foo first. And then reconfigure with
--enable-foo and compile it again. There is a problem because a.vala
was compiled to a.c thinking that package something was present. And
it will probably not compile with someotherthing. a.c will not be
rebuilt because a_vala.stamp is here, and the only test is a "-f $@"
to rebuild or not.

Fourth bug, configure.ac:
AC_INIT
AM_INIT_AUTOMAKE(nonesuch, nonesuch)
AM_PROG_VALAC
AC_PROG_CC
AC_OUTPUT(Makefile)

Makefile.am:
bin_PROGRAMS=a
a_SOURCES=a.vala

then

$ touch a.vala
$ aclocal-1.11a
$ autoconf
$ automake-1.11a
$ mkdir foo
$ cd foo
$ ../configure
$ make
make: *** No rule to make target `../a_vala.stamp', needed by `../a.c'.  Stop.

Of course, it seems that the bootstrap does not work with VPATH. See
the rule in Makefile.in:
a_vala.stamp: $(a_SOURCES)
$(VALAC) $(AM_VALAFLAGS) $(VALAFLAGS) -C $(a_SOURCES)
touch $@

First, it should be $(srcdir)/a_vala.stamp since this file is in the
DIST_COMMON. Then there should be a variable generated by Automake
that contains all that is in $(a_SOURCES) but with $(srcdir) in front
so that the first command of the rule reads the right files.

Fifth bug: AM_PROG_VALAC should require AC_PROG_CC. It does not seem
to do that. As you see all my test cases, I needed to put manually
AC_PROG_CC in the configure.ac.
configure.ac:
AC_INIT
AM_INIT_AUTOMAKE(nonesuch, nonesuch)
AM_PROG_VALAC
AC_OUTPUT(Makefile)

Makefile.am:
bin_PROGRAMS=a
a_SOURCES=a.vala

I think most of the problems are due to the fact that Automake tries
to ship derived source. While it can make sense with Yacc of Lex
because of the direct conversion 1-file to 1-file, it does not seem to
be really scaling to Vala. After all "derived sources" are more
objects that sources. Nobody wants to read or modify the files
generated by Vala. I think it is at least legitimate for the user not
to want to ship the generated .c files, and it is not possible with
the current implementation. Besides it seems that AM_PROG_VALAC
requires valac to be present. It does not define it as `$MISSING
valac' when this one is not here. Why is it required when the .c files
are in the DIST_COMMON?

The definition of a language should be able to be defined as derived
sources, but be able not to push the res

[SOLVED] silent5.test failure (was: Re: Automake 1.11.1 glitch?)

[Stefano Lattarini]

Hello Bob, thanks for helping me through this.

On Tuesday 07 September 2010, Bob Friesenhahn wrote:
> On Tue, 7 Sep 2010, Stefano Lattarini wrote:
> >> tests/silent5.log and config.log are attached.  From
> >> tests/silent5.log I see that 'no' is being passed as a command
> >> to bash, so it is likely that there is a test suite weakness.
> > 
> > Darn, I've been sloppy: I should have also asked you to provide
> > us with the (tarred) content of the temporary test directory
> > `tests/silent5.dir'.  Could you kindly send this over to the list
> > too?
> 
> You've got it Toyota!
Sorry?

> I see that it is 235KB so hopefully it will make it through to
> the list.
It did :-)

And by looking at the files `tests/silent5.dir/Makefile' and 
`tests/silent5.dir/config.log', it's easy to detect the problem.

It seems that you have somehow defined in your environment `F77'
to `no' (probably through your config.site), and the current tests'
setup code in `tests/defs.in'  fails to force the redefintion of
that environment variable to `gfortran' when running a test that
requires a Fortran compiler.  So yes, this is a testsuite weakness.

JFTR, there is a pending patch series of mine that should take care of 
such problems:
  
Reveiews by anyone interested are welcome ;-)

Thanks,
   Stefano

Re: Automake 1.11.1 glitch?

[Stefano Lattarini]

Hi Bob.  Thanks for your answer.

On Tuesday 07 September 2010, Bob Friesenhahn wrote:
> On Tue, 7 Sep 2010, Stefano Lattarini wrote:
> >> The GraphicsMagick test suite passes with this patch.  I do see
> >> one test failure with the Automake test suite
> >> 
> >>FAIL: silent5.test
> >> 
> >> but this test may have been failing prior to the patch.
> > 
> > Could you please send the log of this test (`tests/silent5.log'),
> > togheter with the configure-generated `config.log' and any other
> > information you think might be useful?
> 
> tests/silent5.log and config.log are attached.  From
> tests/silent5.log I see that 'no' is being passed as a command to
> bash, so it is likely that there is a test suite weakness.
> 
Darn, I've been sloppy: I should have also asked you to provide
us with the (tarred) content of the temporary test directory 
`tests/silent5.dir'.  Could you kindly send this over to the list
too?

( to self and to Ralf: it would be nice if the Automake 
testsuite could create, whenever a failure occurs, a tarball containg 
all the relevant logs and the contents of all relevant temporary test
directories, to avoid plaguing the poor bug reporters with continuos 
requests of more details )

Bob, thank you again for your report and your patience,
   Stefano

Re: Automake 1.11.1 glitch?

[Bob Friesenhahn]

On Tue, 7 Sep 2010, Stefano Lattarini wrote:


The GraphicsMagick test suite passes with this patch.  I do see one
test failure with the Automake test suite

   FAIL: silent5.test

but this test may have been failing prior to the patch.

Could you please send the log of this test (`tests/silent5.log'),
togheter with the configure-generated `config.log' and any other
information you think might be useful?


tests/silent5.log and config.log are attached.  From tests/silent5.log 
I see that 'no' is being passed as a command to bash, so it is likely 
that there is a test suite weakness.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/FAIL: silent5.test (exit: 1)


/scratch/bfriesen/build/automake-1.11.1/tests:/usr/local/Trolltech/Qt-4.3.3/bin:/usr/local/bin:/usr/local64/bin:/opt/DTT/bin:/usr/dt/bin:/usr/local/rpm-4.4.2.1/bin:/opt/SUNWspro/extra/bin:/opt/SUNWspro/bin:/usr/local/teTeX/bin:/opt/sfw/netpbm/bin:/opt/sfw/bin:/usr/sfw/bin:/usr/sadm/admin/bin:/usr/ccs/bin:/usr/xpg6/bin:/usr/xpg4/bin:/usr/bin:/usr/sbin:/usr/ucb::/usr/openwin/bin:/usr/openwin/demo:.
silent5: running g++ --version
g++ (GCC) 4.4.4
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

silent5: running gfortran --version
GNU Fortran (GCC) 4.4.4
Copyright (C) 2010 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

silent5: running flex --version
flex 2.5.35
silent5: running bison --version
bison (GNU Bison) 2.4.1
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
=== Running test /home/bfriesen/src/gnu/automake-1.11.1/tests/silent5.test
+ pwd 
/scratch/bfriesen/build/automake-1.11.1/tests/silent5.dir
+ set -e 
+ mkdir sub 
+ cat 
+ cat 
+ cat 
+ cat 
+ cat 
+ cat 
+ cat 
+ cat 
+ cp foo1.cpp bar.c 
+ cp foo1.cpp sub/baz.c 
+ cp foo1.cpp sub/bla.c 
+ cp foo1.cpp sub/baz1.cpp 
+ cp foo2.f90 sub/baz2.f90 
+ cp foo3.f sub/baz3.f 
+ cp foo5.l sub/baz5.l 
+ cp foo6.y sub/baz6.y 
+ aclocal-1.11 -Werror 
+ automake-1.11 --foreign -Werror -Wall --add-missing 
configure.in:5: installing `./compile'
configure.in: installing `./ylwrap'
+ autoconf 
+ ./configure --enable-silent-rules 
configure: loading site script /usr/local/share/config.site
Applying settings for 32-bit build ...
Using GCC 4.4.4 ...
CC   = "gcc-4.4.4"
CXX  = "g++"
F77  = "no"
FC   = "no"
CFLAGS   = "-O2"
CXXFLAGS = "-O"
CPPFLAGS = ""
LDFLAGS  = "-L/usr/local/lib -R/usr/local/lib"
checking for a BSD-compatible install... /usr/local/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/sfw/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc-4.4.4
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc-4.4.4 accepts -g... yes
checking for gcc-4.4.4 option to accept ISO C89... none needed
checking dependency style of gcc-4.4.4... gcc3
checking whether gcc-4.4.4 and cc understand -c and -o together... yes
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether we are using the GNU Fortran 77 compiler... no
checking whether no accepts -g... no
checking whether we are using the GNU Fortran compiler... no
checking whether no accepts -g... no
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking for bison... bison -y
configure: creating ./config.status
config.status: creating Makefile
config.status: creating sub/Makefile
config.status: executing depfiles commands
+ make 
/bin/bash: line 1: no: command not found
make[3]: *** [baz2.o] Error 127
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
+ cat stdout 
  YACC   foo6.c
updating foo6.h
make  all-recursive
make[1]: Entering directory 
`/scratch/bfriesen/build/automake-1.11.1/tests/silent5.dir'
Making all in sub
make[2]: Entering directory 
`/scratch/bfriesen/build/automake-1.11.1/tests/silent5.dir/sub'
  YACC   ba