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