GNOME Bugzilla – Bug 472048
autotools support
Last modified: 2009-05-09 13:23:40 UTC
Vala should ship files for autotools support.
Created attachment 94680 [details] autoconf macros for detecting valac
Created attachment 94681 [details] Script to generate automake rules for vala
Confirming, will investigate how to integrate this best.
Created attachment 96342 [details] [review] Updated version from gtkspellcheck Updating from http://taschenorakel.de/gitweb/?p=gtkspellcheck;a=blob;f=vala-support: 2007-09-28 Sven Herzberg <sven@imendio.com> * vala-support: Correctly express the C -> stamp file dependency to support parallel builds. 2007-09-26 Sven Herzberg <sven@imendio.com> * vala-support: Make Makefile.vm files depend on vala-support. 2007-09-26 Sven Herzberg <sven@imendio.com> * vala-support: Use the basename of the vala file for output files to support non-recursive (auto)make.
So I've bitten the bullet and patched automake: http://taschenorakel.de/gitweb/?p=automake;a=commitdiff;h=aa99f2cdd707ee18a5847a11a30ba9d75e5d6a7d;hp=8e79459e55f37195e70a4c04cb1298a878b3de34 Next step: Submit it to the automake mailing list. Tomorrow.
Thanks a lot, native autotools support will be really nice. I've marked the vala-support version as obsolete as the automake patch is superior. It would be nice if we can get some initial comments from the automake maintainer.
Generally, native Automake support for a new language like vala is great. I haven't looked at the proposed patches on the automake-patches list in detail yet, though, due to its unclear legal status. The FSF requires copyright assignment for nontrivial patches against GNU projects. Matthias, if you've already started the assignment process, please let me know, thanks (I contacted you off-list about this on Sep 30).
Oh, (In reply to comment #7) > Matthias, if you've ^^- one 't'! ;-) > already started the assignment process, please let me know, thanks (I contacted > you off-list about this on Sep 30). Oh, this explains the delay: GMX moved your message to the spam folder: "GMX Spamschutz Spamserver-Blocker: Diese E-Mail wurde nicht über den tatsächlichen Mailserver des Absenderdienstes eingeliefert." Looking at the copyright assigment process now, wondering how the FSF believes being able to do copyright assignment in compliance with German law...
Apologies for misspelling your name. All I know, the FSF copyright assignment is a process that works fine with US law, which is where the FSF is located. (But if you have more questions about it, I'm the wrong person to ask, and will defer to others.)
Request sent.
Ralf, I've sent the paperwork back to the FSF ages ago, so any update on Vala support? http://lists.gnu.org/archive/html/automake-patches/2007-09/msg00007.html
Oh, sorry, this went off my radar. Hope to find some time to look at it soonish.
I tried to apply the patch on autotools-1.10.1 and it produces an unusable automake: muelli@xbox:/$ automake-1.10 --version Possible unintended interpolation of @hidden in string at /opt/gnome2/bin/automake-1.10 line 5508. Global symbol "@hidden" requires explicit package name at /opt/gnome2/bin/automake-1.10 line 5508. BEGIN not safe after errors--compilation aborted at /opt/gnome2/bin/automake-1.10 line 6131. muelli@xbox:/$ muelli@xbox:/$ cat /opt/gnome2/bin/automake-1.10 | head -n $((5508+10)) | tail -n 20 foreach my $file ($var->value_as_list_recursive) { $output_rules .= "$file: ${xname}_vala.stamp\n" if ($file =~ s/(.*)\.vala$/$1.c $1.h/); } } $output_rules .= "${xname}_vala.stamp: \$(${xname}_SOURCES)\n". "\t\$(VALACOMPILE) \$^ && touch address@hidden"; } } # 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) = @_; (my $output_base = $output) =~ s/$KNOWN_EXTENSIONS_PATTERN$//; muelli@xbox:/$
Update here: <http://thread.gmane.org/gmane.comp.sysutils.automake.patches/2860/focus=3219>
It would be very helpful if somebody who knows valac could help me address the issues and questions I stated in said message, <http://thread.gmane.org/gmane.comp.sysutils.automake.patches/2860/focus=3219>. I'm afraid otherwise I won't know how to proceed with Automake on this issue (which effectively means that Vala support then may not be in the next Automake version). Thank you, Ralf
Thanks a lot for your update. I'll try to look into this tomorrow, although, I'm not familiar with the automake codebase.
You should not need to be. The point is: there is no apparent bug in the vala patches for Automake. Rather, the semantics of valac that I observe are different from what the patches describe. I need to know which side is right, and get the wrong bits fixed. If the cited message doesn't contain enough information for you to reproduce the failure, please feel free to ask. It should be a matter of cut and pasting the commands from that message.
(In reply to comment #17) > You should not need to be. The point is: there is no apparent bug in the > vala patches for Automake. Rather, the semantics of valac that I observe > are different from what the patches describe. I need to know which side is > right, and get the wrong bits fixed. > > If the cited message doesn't contain enough information for you to reproduce > the failure, please feel free to ask. It should be a matter of cut and > pasting the commands from that message. > | + make | /usr/bin/valac --library=0 -d src src/zardoz.vala && touch src_zardoz_vala.stamp ... | gcc: ./src/zardoz.c: Datei oder Verzeichnis nicht gefunden do you miss the -C argument to vala produce .c/.h files?
Thanks! -C gets me further. How come it's not documented in the man page? (Is the manpage written by Debian so I should report a bug there?) Next issue: when sources are in subdirs, the include path needs adjustment: $ /usr/bin/valac --library=0 -C -b src -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 src/zardoz.c:2:20: error: zardoz.h: No such file or directory Should automake add -Isrc here, or should zardoz.c use #include <src/zardoz.h> and if the latter, is there a valac switch for this as well? I should also note that the stamp file should probably better be src/zardoz_vala.stamp (but that is a technical detail only).
As far as I can tell, -d (output directory) shouldn't be used in this situation. Can you try whether it works when you use -b $(top_srcdir)? This should automatically adapt the #include directives appropriately.
Yes with '-b .' and without -d, looks better, it generates #include <src/zardoz.h> Alternatively, things would have worked when zardoz.c used #include "zardoz.h" instead of #include <zardoz.h> Why doesn't it do that? The generated header should always live in the same directory, no? Where is detailed documentation for the valac command line switches and semantics? Thanks!
I'm assuming that '-b .' is only an example and you're using '-b $(top_srcdir)', otherwise it will only work with non-recursive make or am I missing something? It seems to be pretty common to use <...> instead of relative paths in public header files of libraries, so I'm following that convention. In private application header files, "..." is probably more commonly used, however, it doesn't really matter that much, or do you see a specific issue with that approach? The only up-to-date documentation about valac command line switches is currently 'valac --help'. I should update/complete the manpage. Are there remaining issues with the automake vala support from your point of view, any further questions? I'll try to look at it later today whether everything makes sense from my perspective. Thanks for working on that, I really appreciate it.
I've taken a first look at the patch now. You've mentioned in your first mail that you don't particularly like the new PKGNAME suffix. I've discussed this with Mathias and we both agree that it's probably better to drop the PKGNAME part and let users just add --library= to _VALAFLAGS, as automake doesn't know about pkg-config in other places, either. I can post a patch to fix this but not sure whether this small change would already require dealing with copyright assignment.
Issues I've found while doing some more testing: The _vala.stamp file should get distributed (otherwise distributing .c and .h files doesn't make sense). Also, the stamp file should be removed on maintainer-clean to force rebuild of .c and .h files. Let me know if this behavior conflicts in some way with existing autotools practice. One potential issue I've noticed is that it's necessary to add -I$(top_srcdir) to CFLAGS if building with recursive make. That's often also necessary in C library projects but it might be non-obvious. Do you think that it would make sense to implicitly add this to the corresponding CFLAGS or rather not? With these issues fixed, I can try to port existing Vala applications and libraries to the new automake support to check whether everything works as expected.
(In reply to comment #22) > I'm assuming that '-b .' is only an example and you're using '-b > $(top_srcdir)', Yes. > otherwise it will only work with non-recursive make or am I > missing something? > It seems to be pretty common to use <...> instead of relative paths in public > header files of libraries, so I'm following that convention. Erm, is zardoz.h in this case a public header? In which sense -- should it be installed by 'make install' for example (doesn't happen ATM). > In private > application header files, "..." is probably more commonly used, however, it > doesn't really matter that much, or do you see a specific issue with that > approach? Well, using "..." is just easier on path issues typically. I don't even know yet whether other files will include zardoz.h, or whether there can be recursive inclusions between headers (at which point the difference will probably become important). > Are there remaining issues with the automake vala support from your point of > view, any further questions? I'll try to look at it later today whether > everything makes sense from my perspective. Well, given the path issues, it would be great to have more run tests, or at least one that is a bit more complex. Basically I would like to have as complete coverage of automake's decision tree as possible, that tends to kill many avoidable bugs. (In reply to comment #23) > I've taken a first look at the patch now. You've mentioned in your first mail > that you don't particularly like the new PKGNAME suffix. I've discussed this > with Mathias and we both agree that it's probably better to drop the PKGNAME > part and let users just add --library= to _VALAFLAGS, as automake doesn't know > about pkg-config in other places, either. I can post a patch to fix this but > not sure whether this small change would already require dealing with copyright > assignment. Generally, every nontrivial patch requires an assignment. The FSF sees 15 lines as a rough limit. If you don't want that, then you can best just describe the needed changes to me or Mathias. (More off-list.) (In reply to comment #24) > The _vala.stamp file should get distributed (otherwise distributing .c and .h > files doesn't make sense). Also, the stamp file should be removed on > maintainer-clean to force rebuild of .c and .h files. Let me know if this > behavior conflicts in some way with existing autotools practice. No conflicts, and good point, thanks! Also, the stamp file should be updated in the source tree. > One potential issue I've noticed is that it's necessary to add -I$(top_srcdir) > to CFLAGS if building with recursive make. That's often also necessary in C > library projects but it might be non-obvious. Do you think that it would make > sense to implicitly add this to the corresponding CFLAGS or rather not? Which inclusion is this necessary for? > With these issues fixed, I can try to port existing Vala applications and > libraries to the new automake support to check whether everything works as > expected. I'll try to amend the branch this weekend for the issues that have been found. Thanks for all the feedback! Ralf
How is the status of this? there seems to be things discussed here that aren't on automake git repository. I tried to decipher what I could (I don't speak perl), and fixed the -C issue. Trying to port one of my toy projects I found another bug : target specific _VALAFLAGS result in automake thinking that the C file is renamed but it's not, and this will give errors such as "no rule to make target-filename.c needed by target-target-filename.o". (just add $AUTOCONF && ./configure && $MAKE to vala.test to see it). Do you see any use case where one would use the same vala file for two different executables and expect the difference to be in the c file (rather than in the object file)? about the "..." vs <...> issue, I think (Jürg, correct me if I'm wrong) that headers of executables (no --library option) use "..." because they are private (btw, the above example shouldn't use --library, I also managed to fix this) and library headers are public and should be installed, hence the use of <...>. I think it would be better to have some use cases so that it's clear what the automake behaviour should be : (Here are some suggestions) 1) How should a library (say mylib-1.0) consisting of file1.vala, file2.vala and file3.vala, and depending on pkg+-2.0 and pkg2-1.0 be built (and installed)? What should be done by automake and what should be left to the user. $ valac -C --pkg pkg+-2.0 --pkg pkg2-1.0 --library mylib-1.0 file1.vala \ file2.vala file3.vala CFLAGS=`pkg-config --cflags pkg+-2.0 pkg2-1.0` [COMPILE] file1.c [COMPILE] file2.c [COMPILE] file3.c LDFLAGS=`pkg-config --libs pkg+-2.0 pkg2-1.0` [LINK] file1.o file2.o file3.o [INSTALL] file1.h file2.h file3.h libmylib-1.0.* mylib-1.0.vapi How about mylib-1.0.gir? Does automake actually know about the vapi? (I think the --library option should be added by automake so that it knows about .vapi and eventually installs it) 2) How about an executable? no --library don't install headers and vapi (vapi and gir won't be generated) What do you think about this? I hope it isn't too long (should I have posted on the mailing list instead?)
Created attachment 125592 [details] [review] My changes to automake
Regarding the header issue, I've started a thread[1] on the mailing list about the topic. When the proposed solution has been implemented, internal header files will no longer be an issue. I don't think that automake should need to know about .vapi and .gir files, assuming that they can be added easily to Makefile.am of projects. It helps if we can keep the build system integration as simple as possible. I'm planning to finish this and get it merged upstream as soon as the header changes in Vala have been completed. I have finished the copyright assignment process some time ago, so I can work on the patch to get it upstream. [1] http://mail.gnome.org/archives/vala-list/2009-January/msg00058.html
What's the state on this? I was under the impression that I should wait for some input, in order to move forward with vala support in Automake. The mh-vala-support in git Automake is still where it was 2008-10-10. It would be nice to fix the issues you know about, so the branch can be merged into the next release; thanks.
There is a change pending in Vala that will affect the generation of header files and therefore integration with build systems. I'm planning to update and complete the automake support as soon as the header generation change is in Vala master - it should actually get a bit simpler on the automake side. Unfortunately, it is taking longer than I expected; I'm still hoping to finish it soon, though. Is there an estimate how much time we still have to get it into the next automake release? Thanks.
(In reply to comment #30) > There is a change pending in Vala that will affect the generation of header > files and therefore integration with build systems. I'm planning to update and > complete the automake support as soon as the header generation change is in > Vala master - it should actually get a bit simpler on the automake side. OK thanks. Is this PR 572536? If yes, have you thought about lazily updating generated headers files (i.e., only change their time stamp if they have changed)? > Is there an estimate how much time we still have to get it into the next > automake release? Thanks. No, but I dearly hope to get to an 1.11a test release soonish. It would be good to have something vala to test then, but if not, the vala branch is one that I would probably be ok to add to 1.11.x, x>0, too.
(In reply to comment #31) > (In reply to comment #30) > > There is a change pending in Vala that will affect the generation of header > > files and therefore integration with build systems. I'm planning to update and > > complete the automake support as soon as the header generation change is in > > Vala master - it should actually get a bit simpler on the automake side. > > OK thanks. Is this PR 572536? If yes, have you thought about lazily updating > generated headers files (i.e., only change their time stamp if they have > changed)? Yes, this is bug 572536. We already do lazy updates for generated C header and source files, otherwise build performance would be a lot worse. Performance is just one aspect, though, there are more issues such as declarations for internal API and header cycles. > > Is there an estimate how much time we still have to get it into the next > > automake release? Thanks. > > No, but I dearly hope to get to an 1.11a test release soonish. It would be > good to have something vala to test then, but if not, the vala branch is one > that I would probably be ok to add to 1.11.x, x>0, too. Ok, thanks. I'll try to get something working as soon as possible and let you know when I have updates for the automake side.
Update: http://article.gmane.org/gmane.comp.sysutils.automake.patches/3515
Initial Vala support has been merged upstream in the meantime. Thanks again to Mathias for the initial patches and Ralf for reviewing, explanations, and fixes. I've sent three more fixes to the automake-patches mailing list and consider this bug now resolved.
great news! thanks all!