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] Vala support for automake
2009/3/31 Ralf Wildenhues ralf.wildenh...@gmx.de: 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. sid has 0.5.7 and there is an Ubuntu PPA at https://launchpad.net/~vala-team/+archive/ppa that should probably work in Debian (though it hasn't been updated to 0.6 yet). So 0.6 isn't easily acquirable yet. The Ubuntu packaging suggests that you need these packages to build from scratch: libglib2.0-dev (= 2.12.0) bison (= 2.3) autotools-dev flex gnome-pkg-tools xsltproc -mt
Vala support for automake
' = 'header', # Nothing to do. '_finish' = sub { }); +# 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); + # Yacc (C C++). register_language ('name' = 'yacc', 'Name' = 'Yacc', @@ -2582,6 +2599,8 @@ sub handle_libraries . did you mean `$suggestion'?) } + ($known_libraries{$onelib} = $bn) =~ s/\.a$//; + $where-push_context (while processing library `$onelib'); $where-set (INTERNAL-get); @@ -2783,6 +2802,8 @@ sub handle_ltlibraries . did you mean `$suggestion'?) } + ($known_libraries{$onelib} = $bn) =~ s/\.la$//; + $where-push_context (while processing Libtool library `$onelib'); $where-set (INTERNAL-get); @@ -5488,6 +5509,15 @@ sub lang_header_rewrite return LANG_IGNORE; } +# Rewrite a single Vala source file. +sub lang_vala_rewrite +{ +my ($directory, $base, $ext) = @_; + +(my $newext = $ext) =~ s/vala$/c/; +return (LANG_SUBDIR, $newext); +} + # Rewrite a single yacc file. sub lang_yacc_rewrite { @@ -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 +if ($file =~ s/(.*)\.vala$/$1.c/); +} +} + + 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 = ${derived}_$flag; + $compile =~ s/\(AM_$flag\)/\($val\)/ +if set_seen ($val); +} + + my $dirname = dirname ($name); + + $compile .= -C; + + $output_rules .= +${derived}_vala.stamp: \$(${derived}_SOURCES)\n. +\t${compile} \$^\n\ttouch \...@\n; + + push_dist_common (${derived}_vala.stamp); + + $clean_files{${derived}_vala.stamp} = MAINTAINER_CLEAN; +} + +# This is a vala helper which is called after all source file +# processing is done. +sub lang_vala_finish +{ + my ($self) = @_; + + foreach my $prog (keys %known_programs) +{ + lang_vala_finish_target ($self, $prog); +} + + while (my ($name) = each %known_libraries) +{ + lang_vala_finish_target ($self, $name); +} +} + +# This is a vala helper which is called whenever we have decided to +# compile a vala file. +sub lang_vala_target_hook +{ + my ($self, $aggregate, $output, $input, %transform) = @_; + + $clean_files{$output} = MAINTAINER_CLEAN; +} + # This is a yacc helper which is called whenever we have decided to # compile a yacc file. sub lang_yacc_target_hook diff --git a/doc/automake.texi b/doc/automake.texi index e1f0f32..1382d5c 100644 --- a/doc/automake.texi +++ b/doc/automake.texi @@ -217,6 +217,7 @@ Building Programs and Libraries * Fortran 77 Support:: Compiling Fortran 77 sources * Fortran 9x Support:: Compiling Fortran 9x sources * Java Support::Compiling Java sources +* Vala Support::Compiling Vala sources * Support for Other Languages:: Compiling other languages * ANSI::Automatic de-ANSI-fication (obsolete) * Dependencies::Automatic dependency tracking @@ -4471,6 +4472,7 @@ to build programs and libraries. * Fortran 77 Support:: Compiling Fortran 77 sources * Fortran 9x Support:: Compiling Fortran 9x sources * Java Support::Compiling Java sources +* Vala Support::Compiling Vala sources * Support for Other Languages:: Compiling other languages * ANSI::Automatic de-ANSI-fication (obsolete) * Dependencies::Automatic dependency tracking @@ -6523,6 +6525,56 @@ using the @option{--main=} option. The easiest way to do this is to use the @code{_LDFLAGS} variable for the program. +...@node Vala Support +...@comment node-name, next, previous, up +...@section Vala Support + +...@cindex Vala Support +...@cindex Support for Vala + +Automake provides support for Vala compilation +(@uref{http://www.vala-project.org/}). + +...@example +foo_SOURCES = foo.vala bar.vala zardoc.c +...@end example + +Any @file{.vala} file listed in a @code{_SOURCE} variable will be +compiled into C code by the Vala compiler. + +Automake ships with an Autoconf macro called @code{AM_PROG_VALAC} +that will locate the Vala compiler and optionally check its
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 = ${derived
Re: Updated Vala support for automake
Hello people interested in Automake support for Vala, (please indicate if you don't want to be Cc:ed.) * Ralf Wildenhues wrote on Sat, Sep 06, 2008 at 08:53:06PM CEST: http://thread.gmane.org/gmane.comp.sysutils.automake.patches/2860/focus=513. I've udpated Mathias' patches to incorporate the suggestions I sent earlier, and pushed the resulting patches to a feature branch that can be found here: git clone git://git.savannah.gnu.org/automake.git git checkout origin/mh-vala-support http://git.savannah.gnu.org/gitweb/?p=automake.git;a=shortlog;h=refs/heads/mh-vala-support Now, I have a couple of issues with the result still, most importantly: it doesn't work yet. :-) I've installed vala support packages on my Debian Lenny (prerelease): $ valac --version Vala 0.3.4 The vala3.test test fails. What happens is that valac creates not .c source from the .vala input file, but instead creates files named: 0.gidl 0.vapi zardoz zardoz.h | + make | /usr/bin/valac --library=0 -d src src/zardoz.vala touch src_zardoz_vala.stamp | gcc -DPACKAGE_NAME=\vala3\ -DPACKAGE_TARNAME=\vala3\ -DPACKAGE_VERSION=\1.0\ -DPACKAGE_STRING=\vala3\ 1.0\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\vala3\ -DVERSION=\1.0\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -I. -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -MT src_zardoz-zardoz.o -MD -MP -MF .deps/src_zardoz-zardoz.Tpo -c -o src_zardoz-zardoz.o `test -f 'src/zardoz.c' || echo './'`src/zardoz.c | gcc: ./src/zardoz.c: Datei oder Verzeichnis nicht gefunden | gcc: no input files | make: *** [src_zardoz-zardoz.o] Fehler 1 Now, who is wrong, the Automake code or valac? FWIW, below is an incremental diff over Mathias' patches; the full patches can be seen in the git tree. After checking out, you can try out the tree with ./bootstrap ./configure make cd tests set x *vala*test shift make check VERBOSE=yes TESTS=$* Thanks, Ralf diff --git a/automake.in b/automake.in index 4693704..a014bd0 100755 --- a/automake.in +++ b/automake.in @@ -783,7 +783,7 @@ register_language ('name' = 'vala', 'Name' = 'Vala', 'config_vars' = ['VALAC'], 'flags' = ['VALAFLAGS'], - 'compile' = '$(VALAC) $(VALAFLAGS) $(AM_VALAFLAGS)', + 'compile' = '$(VALAC) $(AM_VALAFLAGS) $(VALAFLAGS)', 'compiler' = 'VALACOMPILE', 'extensions' = ['.vala'], 'output_extensions' = sub { (my $ext1 = $_[0]) =~ s/vala$/c/; diff --git a/doc/automake.texi b/doc/automake.texi index b4fd0f4..3ea717b 100644 --- a/doc/automake.texi +++ b/doc/automake.texi @@ -6509,50 +6509,52 @@ the @code{_LDFLAGS} variable for the program. @cindex Vala Support @cindex Support for Vala -Automake provides support for Vala compilation. +Automake provides support for Vala compilation +(@uref{http://live.gnome.org/@/Vala}). @example foo_SOURCES = foo.vala bar.vala zardoc.c @end example -Any .vala file listed in a @code{_SOURCE} variable will be compiled -into C code by the Vala compiler. +Any @file{.vala} file listed in a @code{_SOURCE} variable will be +compiled into C code by the Vala compiler. Automake ships with an Autoconf macro called @code{AM_PROG_VALAC} that will locate the Vala compiler and optionally check its version number. [EMAIL PROTECTED] AM_PROG_VALAC ([EMAIL PROTECTED]) - -Check whether the Vala compiler exists in `PATH'. If it is found the -variable VALAC is set. Optionally a minimum release number of the compiler -can be requested. [EMAIL PROTECTED] AM_PROG_VALAC (@ovar{MINIMUM-VERSION}) +Try to find a Vala compiler in @env{PATH}. If it is found, the variable [EMAIL PROTECTED] is set. Optionally a minimum release number of the compiler +can be requested: @example AM_PROG_VALAC([0.1.3]) @end example - @end defmac There are a few variables that are used when compiling Vala sources: @vtable @code - @item VALAC Path to the the Vala compiler. @item VALAFLAGS Additional arguments for the Vala compiler. [EMAIL PROTECTED] AM_VALAFLAGS +The maintainer's variant of @code{VALAFLAGS}. + @item PKGNAME -The pkg-config and VAPI name to use when building Vala based library. +The pkg-config +(@uref{http://www.freedesktop.org/@/software/@/pkgconfig/}) and VAPI +(Vala API definition file) name to use when building Vala based library. @example lib_LTLIBRARIES = libfoo.la libfoo_la_PKGNAME = foo-2.0 libfoo_la_SOURCES = foo.vala @end example - @end vtable diff --git a/lib/am/vala.am b/lib/am/vala.am index e69de29..fa2a23c 100644 --- a/lib/am/vala.am +++ b/lib/am/vala.am @@ -0,0 +1,17 @@ +## automake - create Makefile.in from Makefile.am +## Copyright (C) 2008 Free Software Foundation, Inc. + +## This program is free software; you can
Re: Updated Vala support for automake
Hello Mathias, all, let me please say that I'm a bit ashamed that I put this off for so long. Please accept my apologies. I promise to push this through quickly now. But first of all, thanks for your contributions to Automake! So here we go with a review of http://thread.gmane.org/gmane.comp.sysutils.automake.patches/2860/focus=513. FWIW, I volunteer to fix the issues, if only to make up for my guilty conscience, but see below for help I need and questions I have. Overall, the patches are pretty good. * Mathias Hasselmann wrote on Sat, Sep 29, 2007 at 06:18:56PM CEST: After talking with Jürg today I've updated my patches for Vala support in automake: - forgot to tell automake to distribute some of the files added - non-recursive builds should work now - automake automatically injects the --library switch for Vala libraries now. By default the library's base name is used. Its possible to override it with _PKGNAME variables I'm not overly fond of adding the new PKGNAME prefix, but I guess this is mostly due to the fact that I don't quite understand the value of it yet. The user can just add --library= to _LDFLAGS no? Does vala require to use libtool? If no, then a test without libtool would be good. If yes, maybe AM_PROG_VALA should AC_REQUIRE([AC_PROG_LIBTOOL]). FWIW, it would be logical to merge (squash) the first two patches, and move the change s/AC_PROG_VALA/AM_PROG_VALA/ from the third to the first one, too. More comments to the patches inline. The patches seem to be missing the lib/am/vala.am file. Can you please post it? (My review of the code you posted is a bit incomplete due to the missing file; I will finish that then.) Cheers, and thanks again, Ralf * Mathias Hasselmann wrote on Sat, Sep 29, 2007 at 06:18:56PM CEST: Index: automake.in === RCS file: /cvs/automake/automake/automake.in,v retrieving revision 1.1649 diff -u -r1.1649 automake.in --- automake.in 30 Sep 2007 04:18:20 - 1.1649 +++ automake.in 30 Sep 2007 05:01:27 - @@ -113,7 +113,7 @@ my ($self) = @_; if (defined $self-_finish) { - {$self-_finish} (); + {$self-_finish} (@_); } } @@ -545,6 +545,7 @@ # Keep track of all programs declared in this Makefile, without # $(EXEEXT). @substitution@ are not listed. my %known_programs; +my %known_libraries; # Keys in this hash are the basenames of files which must depend on # ansi2knr. Values are either the empty string, or the directory in @@ -666,6 +667,7 @@ @dist_targets = (); %known_programs = (); +%known_libraries= (); %de_ansi_files = (); @@ -776,6 +778,22 @@ # Nothing to do. '_finish' = sub { }); +# Vala +register_language ('name' = 'vala', +'Name' = 'Vala', +'config_vars' = ['VALAC'], +'flags' = ['VALAFLAGS'], +'compile' = '$(VALAC) $(VALAFLAGS) $(AM_VALAFLAGS)', AM_VALAFLAGS should not come after VALAFLAGS: the user should be able to override the package author. Unless it's the first and not the last flags that win an override. +'compiler' = 'VALACOMPILE', +'extensions' = ['.vala'], +'output_extensions' = sub { (my $ext1 = $_[0]) =~ s/vala$/c/; + (my $ext2 = $_[0]) =~ s/vala$/h/; + return ($ext1, $ext2) }, +'rule_file' = 'vala', +'_finish' = \lang_vala_finish, +'_target_hook' = \lang_vala_target_hook, +'nodist_specific' = 1); + # Yacc (C C++). register_language ('name' = 'yacc', 'Name' = 'Yacc', @@ -2548,6 +2566,8 @@ . did you mean `$suggestion'?) } + ($known_libraries{$onelib} = $bn) =~ s/\.a$//; + $where-push_context (while processing library `$onelib'); $where-set (INTERNAL-get); @@ -2739,6 +2759,8 @@ . did you mean `$suggestion'?) } + ($known_libraries{$onelib} = $bn) =~ s/\.la$//; + $where-push_context (while processing Libtool library `$onelib'); $where-set (INTERNAL-get); @@ -5309,6 +5331,15 @@ return LANG_IGNORE; } +# Rewrite a single Vala source file. +sub lang_vala_rewrite +{ +my ($directory, $base, $ext) = @_; + +(my $newext = $ext) =~ s/vala$/c/; +return (LANG_SUBDIR, $newext); +} + # Rewrite a single yacc file. sub lang_yacc_rewrite { @@ -5467,6 +5498,84 @@ } } +sub lang_vala_finish_target ($$$) +{ + my ($self, $name, $pkgname) = @_; + + my $derived = canonicalize ($name); + my $varname = $derived . '_SOURCES'; + my $var = var ($varname); + + if ($var) +{ + foreach my $file ($var-value_as_list_recursive