Re: Vala support for automake
Of course my testing went a bit overboard before merging, so I actually missed a couple of vala-related failures. Fixed with this patch, pushed to master. (next has been merged into master.) Cheers, Ralf Fix AM_PROG_VALAC version requirement detection. * m4/vala.m4 (AM_PROG_VALAC): Remove `Vala ' from valac --version string before comparing versions. * tests/vala2.test: Require version 0.7.0 for the test. Fixes failures of vala2.test and vala3.test with older valac. diff --git a/m4/vala.m4 b/m4/vala.m4 index d3f73a5..d95734a 100644 --- a/m4/vala.m4 +++ b/m4/vala.m4 @@ -6,7 +6,7 @@ # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. -# serial 3 +# serial 4 # Check whether the Vala compiler exists in `PATH'. If it is found, the # variable VALAC is set. Optionally a minimum release number of the @@ -20,7 +20,7 @@ AC_DEFUN([AM_PROG_VALAC], [AC_MSG_WARN([No Vala compiler found. You will not be able to compile .vala source files.])], [AS_IF([test -n $1], [AC_MSG_CHECKING([$VALAC is at least version $1]) - am__vala_version=`$VALAC --version` + am__vala_version=`$VALAC --version | sed 's/Vala *//'` AS_VERSION_COMPARE([$1], [$am__vala_version], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([yes])], diff --git a/tests/vala2.test b/tests/vala2.test index 6209aa6..a6efba9 100755 --- a/tests/vala2.test +++ b/tests/vala2.test @@ -32,7 +32,7 @@ cat 'configure.in' 'END' AC_PROG_CC AM_PROG_CC_C_O AC_PROG_LIBTOOL -AM_PROG_VALAC +AM_PROG_VALAC([0.7.0]) PKG_CHECK_MODULES([GOBJECT],[gobject-2.0 = 2.10]) AC_CONFIG_FILES([src/Makefile]) AC_OUTPUT @@ -65,7 +65,7 @@ $ACLOCAL $AUTOCONF $AUTOMAKE -a -./configure +./configure || Exit 77 $MAKE $MAKE distcheck $MAKE distclean
Re: Vala support for automake
Hi Jürg, * Jürg Billeter wrote on Wed, Apr 15, 2009 at 08:56:44PM CEST: On Wed, 2009-04-15 at 20:42 +0200, Ralf Wildenhues wrote: I'm looking at adding per-target flag support for vala sources. Say I have baz.vala and want to create from that foo-baz.c foo-baz.h in one valac invocation, as well as bar-baz.c bar-baz.h in another 'valac -D BAR' invocation. Is there some flag I can pass to valac that will use these output names for me? If yes, does it do so without generating intermediate baz.c baz.h files or any other temporary files that have a name which would conflict with parallel make -jN execution? valac does not currently support any transformation on the output names of the .c files. It's not as easy as a simple -o option because you have multiple input and output files per invocation in general (see below). Ah. Good to know. If you think it would make sense to add a --suffix option or similar to valac, I could certainly take a look at it. I think a --prefix option should do the trick, but I haven't thought this through yet. Also, I see that your vala compile passes all sources to valac. Is that intentional (or just because that was good enough)? I.e., if you have bin_PROGRAMS = foo foo_SOURCES = a.c b.vala c.l d.java e.vala do you really want to invoke valac -C a.c b.vala c.l d.java e.vala That was not intentional. valac won't mind unnecessary .c files but will reject files with other extensions. Ah; that looks like a bug we should fix and test. rather than valac -C b.vala e.vala This would be the correct commandline. OK. or even valac -C b.vala valac -C e.vala This would not work, valac requires all Vala source files of the same program / library on the same commandline. The reason is that the source files can depend on each other, but there is no header/include mechanism. Hmm. What if I do something like this: bin_PROGRAMS = foo foo_SOURCES = foo1.vala foo2.vala foo_LDADD = libbar.a noinst_LIBRARIES = libbar.a libbar_a_SOURCES = bar1.vala bar2.vala How would valac cope with the necessarily separate invocations for foo*.vala and bar*.vala? And what happens if you try to put vala code into shared libraries, and use them from other vala code? Thanks, Ralf
Re: Vala support for automake
Hi Ralf, On Thu, 2009-04-16 at 20:49 +0200, Ralf Wildenhues wrote: * Jürg Billeter wrote on Wed, Apr 15, 2009 at 08:56:44PM CEST: On Wed, 2009-04-15 at 20:42 +0200, Ralf Wildenhues wrote: or even valac -C b.vala valac -C e.vala This would not work, valac requires all Vala source files of the same program / library on the same commandline. The reason is that the source files can depend on each other, but there is no header/include mechanism. Hmm. What if I do something like this: bin_PROGRAMS = foo foo_SOURCES = foo1.vala foo2.vala foo_LDADD = libbar.a noinst_LIBRARIES = libbar.a libbar_a_SOURCES = bar1.vala bar2.vala How would valac cope with the necessarily separate invocations for foo*.vala and bar*.vala? And what happens if you try to put vala code into shared libraries, and use them from other vala code? In this case you instruct valac to generate a bar.vapi and a bar.h file and use those files in the program by specifying libbar_a_VALAFLAGS = --library bar -H bar.h foo_VALAFLAGS = bar.vapi A .vapi file contains declarations for Vala libraries, similar to a .h file for C libraries. Thanks, Jürg
Re: Vala support for automake
* Jürg Billeter wrote on Thu, Apr 16, 2009 at 09:02:30PM CEST: On Thu, 2009-04-16 at 20:49 +0200, Ralf Wildenhues wrote: bin_PROGRAMS = foo foo_SOURCES = foo1.vala foo2.vala foo_LDADD = libbar.a noinst_LIBRARIES = libbar.a libbar_a_SOURCES = bar1.vala bar2.vala How would valac cope with the necessarily separate invocations for foo*.vala and bar*.vala? And what happens if you try to put vala code into shared libraries, and use them from other vala code? In this case you instruct valac to generate a bar.vapi and a bar.h file and use those files in the program by specifying libbar_a_VALAFLAGS = --library bar -H bar.h foo_VALAFLAGS = bar.vapi A .vapi file contains declarations for Vala libraries, similar to a .h file for C libraries. How is the semantic relationship between the .vapi name and its library? s/^lib//; s/\.a$//; s/$/.vapi/? What about shared libraries, do they have .vapi's, too? What if I want to build one big shared (or static) library from a set of convenience archives (uninstalled .a libraries with PIC code)? Do you have means to generate a .vapi for the big library from the .vapi's of the several small ones (plus maybe a couple of loose objects, too)? Just trying to find out how far we can push it. Thanks, Ralf
Re: Vala support for automake
Hi Jürg, * Jürg Billeter wrote on Tue, Apr 07, 2009 at 11:20:36PM CEST: I've attached the verbose test log. Thanks. I'm looking at adding per-target flag support for vala sources. Say I have baz.vala and want to create from that foo-baz.c foo-baz.h in one valac invocation, as well as bar-baz.c bar-baz.h in another 'valac -D BAR' invocation. Is there some flag I can pass to valac that will use these output names for me? If yes, does it do so without generating intermediate baz.c baz.h files or any other temporary files that have a name which would conflict with parallel make -jN execution? Also, I see that your vala compile passes all sources to valac. Is that intentional (or just because that was good enough)? I.e., if you have bin_PROGRAMS = foo foo_SOURCES = a.c b.vala c.l d.java e.vala do you really want to invoke valac -C a.c b.vala c.l d.java e.vala rather than valac -C b.vala e.vala or even valac -C b.vala valac -C e.vala ? And if per-target flags are used with multiple input files, how would I specify the renamed output files? Thanks, Ralf
Re: Vala support for automake
Hello Jürg,
very nice. Thanks again for working on this. At a first glance, all I
could find while reading the patch was a trivial s/_SOURCE/_SOURCES/ in
the manual.
Other than that, I haven't yet gotten around to get my system up to date
in order to support Vala 0.7 yet. Would you be so nice as to post
verbose log output for all the vala tests? That is, just
cd tests
for t in path/to/source/tree/tests/*vala*.test; do
$t
done 21 | tee log
and post log, preferably gzip'ed. That will allow me to finish review
before finishing my system.
Some more comments inline.
* Jürg Billeter wrote on Sun, Apr 05, 2009 at 03:45:44PM CEST:
On Tue, 2009-03-31 at 23:15 +0200, Ralf Wildenhues wrote:
* Jürg Billeter wrote on Tue, Mar 31, 2009 at 01:11:55PM CEST:
Thanks for your prompt response. I finally found some time today to
address your comments. I've rebased mh-vala-support branch and my patch
against the 'next' branch and attached the full patch series. I've also
made the necessary changes to get silent-rules mode working with valac.
Cool.
BTW, where can we read about the current semantics of valac?
There is no formal documentation at the moment, the changes performed
recently are described in bug 572536 [1].
OK; thanks. I don't see any apparent issues with that.
More comments inline. Some are rather notes to self, but the more you
can address the better.
I've tried to address as many comments as possible, see my comments
inline.
Very well, thanks!
+# Vala
+register_language ('name' = 'vala',
+'Name' = 'Vala',
+'config_vars' = ['VALAC'],
+'flags' = ['VALAFLAGS'],
+'compile' = '$(VALAC) $(AM_VALAFLAGS) $(VALAFLAGS)',
+'compiler' = 'VALACOMPILE',
+'extensions' = ['.vala'],
+'output_extensions' = sub { (my $ext = $_[0]) =~ s/vala$/c/;
+ return ($ext,) },
+'rule_file' = 'vala',
+'_finish' = \lang_vala_finish,
+'_target_hook' = \lang_vala_target_hook,
+'nodist_specific' = 1);
The nodist_specific setting should be exposed in some test (i.e., after
following recommendations below, there should be a test that fails if
this setting is removed).
I'm not familiar enough with nodist_ sources, can you help here?
Sure. This really was more of a note to self. I will address this
later. Right now, I'm not positively sure myself about this, but I
think the idea is that distributed sources are updated in the source
tree while nodist_ sources are updated in the build tree. If both
distributed and non-distributed sources exist in the same makefile, only
one of the two sets may be treated by inference rules, but IIRC automake
can pick either one, while the other has to use per-target rules.
I think this is about choosing which way to treat with inference rules.
Note that here, the question of distribution or not is about whether
*.vala files are distributed or not; they could also be generated, say.
If they are not distributed, then of course it does not make sense to
distributed the generated *.c files either. Conversely, if the *.c are
distributed, then their *.vala inputs should also be distributed.
+ if ($var)
+{
+ foreach my $file ($var-value_as_list_recursive)
+{
+ $output_rules .= $file: ${derived}_vala.stamp ;\n
Hmm. This doesn't look like one of the approaches mentioned in
info Automake Multiple Outputs
I've added the recover from removal commands recommended in the
documentation.
Good.
This renaming of outputs is necessary for something like
bin_PROGRAMS = foo bar
foo_SOURCES = baz.vala
bar_SOURCES = baz.vala
bar_VALAFLAGS = -bla
where the -bla flag causes the .c files for foo and bar to be different.
This should be exposed in the testsuite (as XFAIL if it is not fixed).
Done (as XFAIL).
+ # Rewrite each occurrence of `AM_$flag' in the compile
+ # rule into `${derived}_$flag' if it exists.
+ for my $flag (@{$self-flags})
+{
+ my $val = ${derived}_$flag;
+ $compile =~ s/\(AM_$flag\)/\($val\)/
+if set_seen ($val);
+}
Is this exposed in the testsuite additions (i.e., if you remove this
loop, does a test fail)?
No, the testsuite does not seem to test this. This loop appears to have
been copied by Mathias from other places in automake.in. I don't know
how to properly test this.
If you have bar_VALAFLAGS in Makefile.am, then that, instead of
AM_VALAFLAGS, should appear in the rule which runs valac for
bar_SOURCES. The vala5.test uses this; but since the test is XFAIL,
it doesn't expose it yet.
The outputs need to be renamed (see above) if per-target flags are used.
Per-target vala flags are marked as XFAIL as noted above.
Do you intend to work on this? Are there issues impeding a resolution
of
Re: Vala support for automake
Hello Jürg,
* Jürg Billeter wrote on Tue, Mar 31, 2009 at 01:11:55PM CEST:
I've updated the Vala support patches initially written by Mathias
Hasselmann to fix a few issues and to conform to the reworked header
file generation in Vala 0.7.
Thanks for your work on this. I see your patch is based on current
Automake git master. If you like, you can rebase it against the 'next'
branch, which has currently the most recent beta. Or as a rediff
against the mh-vala-support branch, that would have the aesthetic
advantage of showing which parts were contributed by Mathias and which
parts by you.
Anyway, no need to do either of this. The rebase to next should be
a trivial merge though, and all that should be fixed up is a 'lder'
entry in the register_language call, so that silent-rules mode works
nicely with valac.
BTW, where can we read about the current semantics of valac?
Where can I get a recent vala compiler to install, and if there isn't an
unofficial Debian package for it yet (and the build-deps have changed
compared to 0.5.7.1), what other packages do I need to install it?
Thanks.
It appears to work well with a simple test
project including correct distcheck and maintainer-clean functionality.
We need to work on this. It is by far the single way to shake out bugs
very quickly. A list of things that need to be tested listed below.
The Vala support is intended to be used with the upcoming Vala 0.7
release series (git master) and all later versions. Earlier versions may
work with some limitations (e.g., only recursive make). Vala 0.7.0 is
expected to be released this week.
Should the section about Vala support in the Automake manual (and the
NEWS addition) mention that 0.7 is the earliest Vala version this is
suitable with (if that is indeed the case)?
More comments inline. Some are rather notes to self, but the more you
can address the better.
* automake.in: Add %known_libraries, lang_vala_rewrite,
lang_vala_finish and lang_vala_target_hook to support the Vala
programming language. Register Vala language hooks.
* doc/automake.texi, NEWS: Document Vala support.
* lib/am/vala.am: Empty rules file to prevent creation of depend2
based rules for Vala code.
* lib/am/Makefile.am (dist_am_DATA): Add vala.am.
* m4/vala.m4: Provide AM_PROG_VALAC for detecting the Vala compiler.
* m4/Makefile.am (dist_m4data_DATA): Add vala.m4.
* tests/vala.test: Test Vala support.
* tests/vala1.test: Test .c file generation.
* tests/vala2.test: Test recursive make.
* tests/vala3.test: Test non-recursive make.
* tests/vala4.test: Test AM_PROG_VALAC.
* tests/Makefile.am: Update.
Based on patch by Mathias Hasselmann.
I'd like to add Mathias to ChangeLog, and both of you to THANKS before
committing.
+# Vala
+register_language ('name' = 'vala',
+'Name' = 'Vala',
+'config_vars' = ['VALAC'],
+'flags' = ['VALAFLAGS'],
+'compile' = '$(VALAC) $(AM_VALAFLAGS) $(VALAFLAGS)',
+'compiler' = 'VALACOMPILE',
+'extensions' = ['.vala'],
+'output_extensions' = sub { (my $ext = $_[0]) =~ s/vala$/c/;
+ return ($ext,) },
+'rule_file' = 'vala',
+'_finish' = \lang_vala_finish,
+'_target_hook' = \lang_vala_target_hook,
+'nodist_specific' = 1);
The nodist_specific setting should be exposed in some test (i.e., after
following recommendations below, there should be a test that fails if
this setting is removed).
@@ -5646,6 +5676,73 @@ sub lang_c_finish
}
}
+sub lang_vala_finish_target ($$)
+{
+ my ($self, $name) = @_;
+
+ my $derived = canonicalize ($name);
+ my $varname = $derived . '_SOURCES';
+ my $var = var ($varname);
+
+ if ($var)
+{
+ foreach my $file ($var-value_as_list_recursive)
+{
+ $output_rules .= $file: ${derived}_vala.stamp ;\n
Hmm. This doesn't look like one of the approaches mentioned in
info Automake Multiple Outputs
(should be tested with some non-GNU make).
+if ($file =~ s/(.*)\.vala$/$1.c/);
The outer parentheses are not necessary here.
The translation here is not correct if per-target flags (VALAFLAGS) are
used. The Makefile.in generated by vala.test shows this: DIST_COMMON
lists zardoz-zardoz.c and maintainer-clean removes it, but the rule is
only for zardoz.c.
This renaming of outputs is necessary for something like
bin_PROGRAMS = foo bar
foo_SOURCES = baz.vala
bar_SOURCES = baz.vala
bar_VALAFLAGS = -bla
where the -bla flag causes the .c files for foo and bar to be different.
This should be exposed in the testsuite (as XFAIL if it is not fixed).
+}
+}
+
+ my $compile = $self-compile;
+
+ # Rewrite each occurrence of `AM_$flag' in the compile
+ # rule into `${derived}_$flag' if it exists.
+ for my $flag (@{$self-flags})
+{
+ my $val =
