bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Five bugs in Vala integration


From: Valentin David
Subject: Five bugs in Vala integration
Date: Tue, 7 Sep 2010 19:02:09 +0200

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 result into DIST_COMMON like the
current implementation does. It should be to the discretion of the
language definition. (see handle_single_transform)

Then for the third bug the stamp technique does not work in case of
change of conditionals. Maybe there should be one stamp for each set
of conditionals (all but only those for which the program is
dependent). So that at the end we are sure the files are recompiled in
case the conditional definitions changed.

Best regards,
-- 
Valentin David
address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]