| Message ID | 1454428908-7183-1-git-send-email-gustavo@zacarias.com.ar |
|---|---|
| State | Superseded |
| Headers | show |
Gustavo, On Tue, 2 Feb 2016 13:01:46 -0300, Gustavo Zacarias wrote: > +# We wrap vala & valac to point to the proper gir and vapi data dirs > +# Otherwise we'll get host directory data which isn't enough > +define HOST_VALA_INSTALL_WRAPPER > + $(INSTALL) -D -m 0755 package/vala/vala-wrapper \ > + $(HOST_DIR)/usr/bin/vala > + $(INSTALL) -D -m 0755 package/vala/vala-wrapper \ > + $(HOST_DIR)/usr/bin/valac > + $(SED) 's,@VALA_VERSION@,$(VALA_VERSION_MAJOR),' \ > + $(HOST_DIR)/usr/bin/vala > + $(SED) 's,@STAGING_DIR@,$(STAGING_DIR),g' \ > + $(HOST_DIR)/usr/bin/vala > + $(SED) 's,@VALA_VERSION@,$(VALA_VERSION_MAJOR),' \ > + $(HOST_DIR)/usr/bin/valac > + $(SED) 's,@STAGING_DIR@,$(STAGING_DIR),g' \ > + $(HOST_DIR)/usr/bin/valac > +endef > +HOST_VALA_POST_INSTALL_HOOKS += HOST_VALA_INSTALL_WRAPPER So if I understand correctly, the idea is to replace the vala -> vala-3.0 and valac -> valac-3.0 symbolic links by wrappers. So I did a test, first without your patch, with a stupid vala hello world program: thomas@skate:~/projets/buildroot (next)$ cat > pouet.vala class Demo.HelloWorld : GLib.Object { public static int main(string[] args) { stdout.printf("Hello, World\n"); return 0; } } thomas@skate:~/projets/buildroot (next)$ ./output/host/usr/bin/vala pouet.vala Hello, World thomas@skate:~/projets/buildroot (next)$ ./output/host/usr/bin/valac pouet.vala thomas@skate:~/projets/buildroot (next)$ file pouet pouet: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d13ab11a4b8d24623f8ead3e8e3c1c9e73d16df0, not stripped So, the program runs fine on the host with "vala", and compiles to a x86-64 executable. Not really surprising since it's a host-vala installation not tuned for cross-compilation. Then, I apply your patch, rebuild host-vala, and do the same test: thomas@skate:~/projets/buildroot (next)$ ./output/host/usr/bin/vala pouet.vala error: --girdir=/home/thomas/projets/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/share/gir-1.0 not found What package is supposed to install gir-1.0 in staging ? thomas@skate:~/projets/buildroot (next)$ ./output/host/usr/bin/valac pouet.vala thomas@skate:~/projets/buildroot (next)$ file pouet pouet: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d13ab11a4b8d24623f8ead3e8e3c1c9e73d16df0, not stripped But it still compiles to a host binary. Am I missing something ? Could you improve the commit log with more explanations for people (like me) who don't know vala, and don't understand what your patch is fixing exactly ? Thanks! Thomas
On 21/02/16 18:28, Thomas Petazzoni wrote: > So if I understand correctly, the idea is to replace the vala -> > vala-3.0 and valac -> valac-3.0 symbolic links by wrappers. Hi, yes. > So I did a test, first without your patch, with a stupid vala hello > world program: > > thomas@skate:~/projets/buildroot (next)$ cat > pouet.vala > class Demo.HelloWorld : GLib.Object { > > public static int main(string[] args) { > > stdout.printf("Hello, World\n"); > > return 0; > } > } > thomas@skate:~/projets/buildroot (next)$ ./output/host/usr/bin/vala pouet.vala > Hello, World > thomas@skate:~/projets/buildroot (next)$ ./output/host/usr/bin/valac pouet.vala > thomas@skate:~/projets/buildroot (next)$ file pouet > pouet: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d13ab11a4b8d24623f8ead3e8e3c1c9e73d16df0, not stripped > > So, the program runs fine on the host with "vala", and compiles to a > x86-64 executable. Not really surprising since it's a host-vala > installation not tuned for cross-compilation. > > Then, I apply your patch, rebuild host-vala, and do the same test: > > thomas@skate:~/projets/buildroot (next)$ ./output/host/usr/bin/vala pouet.vala > error: --girdir=/home/thomas/projets/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/share/gir-1.0 not found > > What package is supposed to install gir-1.0 in staging ? vala isn't normally used, only valac & vapigen are, so your usage doesn't mirror reality with packages that we currently ship. IIRC "vala" is a deprecated form of invocation from several years ago, still kept for compatibility purposes. And valac doesn't mind if the directory isn't present. That being said, gir-1.0 comes from enabling gobject-introspection which i have as a WIP patchset but haven't submitted yet. I've tested this patchset and it doesn't break our current host-vala using packages. > thomas@skate:~/projets/buildroot (next)$ ./output/host/usr/bin/valac pouet.vala > thomas@skate:~/projets/buildroot (next)$ file pouet > pouet: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d13ab11a4b8d24623f8ead3e8e3c1c9e73d16df0, not stripped > > But it still compiles to a host binary. Am I missing something ? Yes, you need to pass full build env variables (CC & friends) to it, it doesn't work magically. > Could you improve the commit log with more explanations for people > (like me) who don't know vala, and don't understand what your patch is > fixing exactly ? It's part of the webkitgtk/midori major bump, which depends on libgtk3, which depends on libepoxy patching outside x11r7, which depends on these as well. And, by the way, the webkitgtk bump accounts for like 40+ security bugs from http://webkitgtk.org/security/WSA-2015-0002.html And there are no plans to backport those to 2.4.x Currently i've got the 2.10.x (the latest stable branch) patchset cooked up, and 2.12.x is coming soon - we're 3 major releases behind. What this solves is pretty simple, if you try to build a vala app (like midori) which uses vala bindings (vapi) from others it will fail, miserably, because it can't find them (they're in staging, and host-vala as it is will search for them in the host dir -> not found -> boom). Like this: ----- make[3]: Entering directory '/home/gustavoz/b/midori.wayland/output/build/midori-0.5.11' error: [ 1%] Generating nn.gmo Package make[3]: Leaving directory '/home/gustavoz/b/midori.wayland/output/build/midori-0.5.11' `granite' not found in specified Vala API directories or GObject-Introspection GIR directories ----- We haven't seen this because the only applications in buildroot that use vala, gmpc and midori (not bumped) don't use vala bindings. But for the midori bump granite is highly recommended (building without it is likely going away for the next release), hence i've added libgee and granite which are prereqs for usability/friendlyness. The thing is keeping all of this split is quite an amount of work, keeping in sync/rebasing against master and so on. I've been sending what most i could in split sets to keep gtk3, wayland and webkitgtk going forward in a reasonable way. However my patience is wearing quite thin and i'm very tempted to just let everything stale, we're about to ship another release with non-existant gtk3-wayland support again, a feature that was working just fine a few releases ago. Heck, now that i remember not even the webkitgtk24 patches in patchwork are in the release/tree, and the multimedia one fixes autobuilder failures with the new dep checking (Peter pointed me to it on IRC), besides making life terribly easier for people wanting the video/audio features without hunting for many gstreamer options. The rpi one also fixes and autobuilder failure, why do i care again? Also if anybody is fool enough to think qt webkit is in better shape better read: https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ ...and sleep on it. Regards.
Hi Gustavo, On 02/22/16 02:22, Gustavo Zacarias wrote: > The thing is keeping all of this split is quite an amount of work, keeping in > sync/rebasing against master and so on. I can imagine! > I've been sending what most i could in split sets to keep gtk3, wayland and > webkitgtk going forward in a reasonable way. Sounds like a good idea. > However my patience is wearing quite thin and i'm very tempted to just let > everything stale, we're about to ship another release with non-existant > gtk3-wayland support again, a feature that was working just fine a few releases > ago. I'm not sure what your message is here. Do you mean that it's problematic that we have 291 patches left in patchwork, just after Thomas did about 70 commits? I think we all agree on that, so if you have a solution, please let us know. Or do you mean that we should just apply your patches without review? Or are you complaining that of the 365 patches you submitted since 2015.11, only 338 were merged up to now? Regards, Arnout
On 02/02/16 17:01, Gustavo Zacarias wrote: > vala/valac can use gir and vapi data files installed by other packages, > but since these are normally installed to staging and host-vala looks > for them in the host directory (logically) this leads to failure. > So wrap them to call the real tool and add this information via > command-line parameters to them. > > This is required for libgee-granite vala-in-vala bindings. > > Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> > --- > package/vala/vala-wrapper | 2 ++ > package/vala/vala.mk | 18 ++++++++++++++++++ > 2 files changed, 20 insertions(+) > create mode 100644 package/vala/vala-wrapper > > diff --git a/package/vala/vala-wrapper b/package/vala/vala-wrapper > new file mode 100644 > index 0000000..ea0bd09 > --- /dev/null > +++ b/package/vala/vala-wrapper > @@ -0,0 +1,2 @@ > +#!/bin/sh > +$0-@VALA_VERSION@ --vapidir=@STAGING_DIR@/usr/share/vala/vapi --girdir=@STAGING_DIR@/usr/share/gir-1.0 $@ This makes it non-relocatable. Instead, just use the ${STAGING_DIR} that is passed in the environment. That means you can't use vala/c outside of buildroot, but I don't think that's an issue, right? > diff --git a/package/vala/vala.mk b/package/vala/vala.mk > index 56d4db3..5267f68 100644 > --- a/package/vala/vala.mk > +++ b/package/vala/vala.mk > @@ -16,4 +16,22 @@ HOST_VALA_DEPENDENCIES = host-bison host-flex host-libglib2 > # available". > HOST_VALA_CONF_ENV = ac_cv_path_XSLTPROC=: > > +# We wrap vala & valac to point to the proper gir and vapi data dirs > +# Otherwise we'll get host directory data which isn't enough > +define HOST_VALA_INSTALL_WRAPPER > + $(INSTALL) -D -m 0755 package/vala/vala-wrapper \ > + $(HOST_DIR)/usr/bin/vala > + $(INSTALL) -D -m 0755 package/vala/vala-wrapper \ > + $(HOST_DIR)/usr/bin/valac > + $(SED) 's,@VALA_VERSION@,$(VALA_VERSION_MAJOR),' \ > + $(HOST_DIR)/usr/bin/vala > + $(SED) 's,@STAGING_DIR@,$(STAGING_DIR),g' \ > + $(HOST_DIR)/usr/bin/vala > + $(SED) 's,@VALA_VERSION@,$(VALA_VERSION_MAJOR),' \ > + $(HOST_DIR)/usr/bin/valac I would handle vala and valac in a singel SED line. Regards, Arnout > + $(SED) 's,@STAGING_DIR@,$(STAGING_DIR),g' \ > + $(HOST_DIR)/usr/bin/valac > +endef > +HOST_VALA_POST_INSTALL_HOOKS += HOST_VALA_INSTALL_WRAPPER > + > $(eval $(host-autotools-package)) >
On 22/02/16 20:47, Arnout Vandecappelle wrote: > Hi Gustavo, Hi. >> However my patience is wearing quite thin and i'm very tempted to just let >> everything stale, we're about to ship another release with non-existant >> gtk3-wayland support again, a feature that was working just fine a few releases >> ago. > > I'm not sure what your message is here. Do you mean that it's problematic that > we have 291 patches left in patchwork, just after Thomas did about 70 commits? I > think we all agree on that, so if you have a solution, please let us know. Or do > you mean that we should just apply your patches without review? Or are you > complaining that of the 365 patches you submitted since 2015.11, only 338 were > merged up to now? I was asked to step in and maintain webkitgtk, gtk3 & accesory packages. And this has been sitting in patchwork for quite some time with no comments or anything and rotting down (this = the gtk3 bump and other pieces that depend on it). It means i'll just take is as there's no interest and just leave it rot completely - i didn't pick this up because it's something i use or have any particular interest in. If you're implying i don't help in other aspects and i just care about what i send i suggest you take a look at lots of autobuilder fixes for packages i never use. Regards.
On 22/02/16 20:48, Arnout Vandecappelle wrote: >> +#!/bin/sh >> +$0-@VALA_VERSION@ --vapidir=@STAGING_DIR@/usr/share/vala/vapi --girdir=@STAGING_DIR@/usr/share/gir-1.0 $@ > > This makes it non-relocatable. Instead, just use the ${STAGING_DIR} that is > passed in the environment. That means you can't use vala/c outside of buildroot, > but I don't think that's an issue, right? Hi. Not more so than the pkg-config wrapper or the toolchain wrapper, which i can bet is more used/important than this one. Regards.
On 02/23/16 01:27, Gustavo Zacarias wrote: > On 22/02/16 20:48, Arnout Vandecappelle wrote: > > >> +#!/bin/sh > >> +$0-@VALA_VERSION@ --vapidir=@STAGING_DIR@/usr/share/vala/vapi > >> --girdir=@STAGING_DIR@/usr/share/gir-1.0 $@ > > > > This makes it non-relocatable. Instead, just use the ${STAGING_DIR} that is > > passed in the environment. That means you can't use vala/c outside of buildroot, > > but I don't think that's an issue, right? > > Hi. > Not more so than the pkg-config wrapper or the toolchain wrapper, which i can > bet is more used/important than this one. Both of which should be fixed as well. But let's try to avoid adding more non-relocatable stuff, when possible and easy. Regards, Arnout
On 02/23/16 01:18, Gustavo Zacarias wrote: > On 22/02/16 20:47, Arnout Vandecappelle wrote: > >> Hi Gustavo, > > Hi. > >>> However my patience is wearing quite thin and i'm very tempted to just let >>> everything stale, we're about to ship another release with non-existant >>> gtk3-wayland support again, a feature that was working just fine a few releases >>> ago. >> >> I'm not sure what your message is here. Do you mean that it's problematic that >> we have 291 patches left in patchwork, just after Thomas did about 70 commits? I >> think we all agree on that, so if you have a solution, please let us know. Or do >> you mean that we should just apply your patches without review? Or are you >> complaining that of the 365 patches you submitted since 2015.11, only 338 were >> merged up to now? > > I was asked to step in and maintain webkitgtk, gtk3 & accesory packages. > And this has been sitting in patchwork for quite some time with no comments or > anything and rotting down (this = the gtk3 bump and other pieces that depend on > it). > It means i'll just take is as there's no interest and just leave it rot > completely - i didn't pick this up because it's something i use or have any > particular interest in. I think you should take it as: between the 291 - sorry, 300 by now - other patches, this series has been overlooked. Again, if you have ideas that can help to reduce the backlog from 300 to, say, 30: everybody will be glad to hear it! Well, except if your idea is to stop sending patches of course. > If you're implying i don't help in other aspects and i just care about what i > send i suggest you take a look at lots of autobuilder fixes for packages i never > use. That's why I mentioned that 92% of the patches you submitted have already been applied. The other buildroot contributors really appreciate the work you do. And share your frustration that too many patches tend to linger, and need to be rebased all the time. In fact, Thomas and Peter have the additional frustration that all of their time is taken up by applying other people's patches, leaving no time to work on their own ideas. Regards, Arnout
On 22/02/16 21:40, Arnout Vandecappelle wrote: >> If you're implying i don't help in other aspects and i just care about what i >> send i suggest you take a look at lots of autobuilder fixes for packages i never >> use. > > That's why I mentioned that 92% of the patches you submitted have already been > applied. The other buildroot contributors really appreciate the work you do. And > share your frustration that too many patches tend to linger, and need to be > rebased all the time. In fact, Thomas and Peter have the additional frustration > that all of their time is taken up by applying other people's patches, leaving > no time to work on their own ideas. Oh come on, you're smarter than that: most of my merged patches are trivial. That's the consequence of let's call them "big series" lingering on forever - it really demotivates to work on anything groundbreaking since you've gotta rebase forever to keep them sane on top of other changes with nothing happening to it. How about relinquising some control? Add a new committer, maybe Yann, yourself or some other trusted volunteer, that way the new committer(s) can clean up the simple queue and leave the more contentious series for the more experienced ones. Maybe put on some simple ground rules like don't commit your own stuff and so on. They will make mistakes, sure, but then everybody does and both Peter & Thomas will get some free time for their particular interests. Otherwise we end up with these emails that make a lot of noise and then everything cools down and nothing changes, the scaling remains at the same sucklevel. It's not a life-forever thing, if it doesn't work then try some other thing, but if there's no trying for some new approach evidently nothing will change no matter how much you push for new blood, reviews, tested and acks. Regards.
Hello Gustavo, On Mon, 22 Feb 2016 21:18:15 -0300, Gustavo Zacarias wrote: > I was asked to step in and maintain webkitgtk, gtk3 & accesory packages. > And this has been sitting in patchwork for quite some time with no > comments or anything and rotting down (this = the gtk3 bump and other > pieces that depend on it). > It means i'll just take is as there's no interest and just leave it rot > completely - i didn't pick this up because it's something i use or have > any particular interest in. > If you're implying i don't help in other aspects and i just care about > what i send i suggest you take a look at lots of autobuilder fixes for > packages i never use. As Arnout said, all our patches are definitely appreciated, and most of them are applied really quickly. Some of them indeed take more time, but there's nothing personal against you: we have ~300 other patches sitting in patchwork. However, you are almost never helping us by reviewing/testing patches from others. Due to this, instead of applying your patches, I have to review and test patches from other contributors. Conclusion: if you want your patches to be applied faster, the best way is to help the community by reviewing and testing patches. Your review and test effort would be really valuable: you are a long-time Buildroot developer, so you know all the best practices, usual pitfalls and all, which means that we trust your review. Thanks a lot! Thomas
On 02/23/16 02:06, Gustavo Zacarias wrote: > How about relinquising some control? Add a new committer, maybe Yann, yourself > or some other trusted volunteer, that way the new committer(s) can clean up the > simple queue and leave the more contentious series for the more experienced > ones. Maybe put on some simple ground rules like don't commit your own stuff and > so on. This could indeed be a good idea. One reason to limit the number of committers was to avoid conflicts (i.e. two committers working on the same patch in parallel), but as I understand it, Thomas and Peter noticed that this isn't really a problem in practice. So indeed, having a third person that applies trivial patches could be worthwhile to try. That said, Yann and I are already spending a large part of our buildroot time on reviewing patches. I don't think that applying them immediately is going to make that much of a difference. Regards, Arnout
Hello, On Tue, 23 Feb 2016 10:42:24 +0100, Arnout Vandecappelle wrote: > This could indeed be a good idea. One reason to limit the number of committers > was to avoid conflicts (i.e. two committers working on the same patch in > parallel), but as I understand it, Thomas and Peter noticed that this isn't > really a problem in practice. > > So indeed, having a third person that applies trivial patches could be > worthwhile to try. > > That said, Yann and I are already spending a large part of our buildroot time > on reviewing patches. I don't think that applying them immediately is going to > make that much of a difference. Fully agreed: applying the patch is clearly not what takes time. It's a mechanical and stupid operation. What takes time is that when there is no Acked-by/Reviewed-by/Tested-by from a trusted person and the patch is not obviously trivial, then I have to go review the patch myself entirely. Download the source code, check that the license is correct, verify that optional dependencies are properly handled, build in a few basic situations, etc. All those steps I skip when there has been some previous A/R/T tags given by trusted persons. When I see that Arnout or Yann has started reviewing a specific patch or patch series, I assume that they will continue to handle the discussion with the submitter until they give their Acked-by/Reviewed-by. And therefore, I simply skip that patch or patch series, and move on to other topics. So what *really* saves time is people reviewing and testing patches. Of course, the more "trusted" those persons are, the more valuable this effort is. Gustavo, you're a person with a high trust, but unfortunately, you're doing none of this review/testing effort. Best regards, Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > Hello, > On Tue, 23 Feb 2016 10:42:24 +0100, Arnout Vandecappelle wrote: >> This could indeed be a good idea. One reason to limit the number of committers >> was to avoid conflicts (i.e. two committers working on the same patch in >> parallel), but as I understand it, Thomas and Peter noticed that this isn't >> really a problem in practice. >> >> So indeed, having a third person that applies trivial patches could be >> worthwhile to try. >> >> That said, Yann and I are already spending a large part of our buildroot time >> on reviewing patches. I don't think that applying them immediately is going to >> make that much of a difference. > Fully agreed: applying the patch is clearly not what takes time. It's a > mechanical and stupid operation. Agreed. I'm all for ways of improving our ways of working, but I don't think this will change much. Adding Thomas as a co-maintainer has imho been very good, but adding a 3rd committer without having more reviewers imho won't make any significant difference.
On 02/23/16 10:48, Thomas Petazzoni wrote: > Hello, > > On Tue, 23 Feb 2016 10:42:24 +0100, Arnout Vandecappelle wrote: > >> This could indeed be a good idea. One reason to limit the number of committers >> was to avoid conflicts (i.e. two committers working on the same patch in >> parallel), but as I understand it, Thomas and Peter noticed that this isn't >> really a problem in practice. >> >> So indeed, having a third person that applies trivial patches could be >> worthwhile to try. >> >> That said, Yann and I are already spending a large part of our buildroot time >> on reviewing patches. I don't think that applying them immediately is going to >> make that much of a difference. > > Fully agreed: applying the patch is clearly not what takes time. It's a > mechanical and stupid operation. > > What takes time is that when there is no Acked-by/Reviewed-by/Tested-by > from a trusted person and the patch is not obviously trivial, then I > have to go review the patch myself entirely. Download the source code, > check that the license is correct, verify that optional dependencies > are properly handled, build in a few basic situations, etc. All those > steps I skip when there has been some previous A/R/T tags given by > trusted persons. > > When I see that Arnout or Yann has started reviewing a specific patch > or patch series, I assume that they will continue to handle the > discussion with the submitter until they give their > Acked-by/Reviewed-by. And therefore, I simply skip that patch or patch > series, and move on to other topics. > > So what *really* saves time is people reviewing and testing patches. Of > course, the more "trusted" those persons are, the more valuable this > effort is. Gustavo, you're a person with a high trust, but > unfortunately, you're doing none of this review/testing effort. There is one indirect gain, however. In case something needs to be fixed up (not quite the majority but still a significant subset of the patches), then Yann and I currently just give comments and wait for a v2 of the patch. This often leads to several iterations. Fixing the patch right away and pushing it will take less time. Regards, Arnout
Arnout, On Tue, 23 Feb 2016 20:43:44 +0100, Arnout Vandecappelle wrote: > > So what *really* saves time is people reviewing and testing patches. Of > > course, the more "trusted" those persons are, the more valuable this > > effort is. Gustavo, you're a person with a high trust, but > > unfortunately, you're doing none of this review/testing effort. > > There is one indirect gain, however. In case something needs to be fixed up > (not quite the majority but still a significant subset of the patches), then > Yann and I currently just give comments and wait for a v2 of the patch. This > often leads to several iterations. Fixing the patch right away and pushing it > will take less time. This is true. One quick and simple workaround to this issue is that when you are in such a situation, just pick-up the patch and resend it for your minor fixes. Of course, if the minor fix is really super trivial, then just indicate it in your review, and Peter and I can fix that up. But if the requested changes are a bit more significant, it does make sense to resend the patch. Best regards, Thomas
diff --git a/package/vala/vala-wrapper b/package/vala/vala-wrapper new file mode 100644 index 0000000..ea0bd09 --- /dev/null +++ b/package/vala/vala-wrapper @@ -0,0 +1,2 @@ +#!/bin/sh +$0-@VALA_VERSION@ --vapidir=@STAGING_DIR@/usr/share/vala/vapi --girdir=@STAGING_DIR@/usr/share/gir-1.0 $@ diff --git a/package/vala/vala.mk b/package/vala/vala.mk index 56d4db3..5267f68 100644 --- a/package/vala/vala.mk +++ b/package/vala/vala.mk @@ -16,4 +16,22 @@ HOST_VALA_DEPENDENCIES = host-bison host-flex host-libglib2 # available". HOST_VALA_CONF_ENV = ac_cv_path_XSLTPROC=: +# We wrap vala & valac to point to the proper gir and vapi data dirs +# Otherwise we'll get host directory data which isn't enough +define HOST_VALA_INSTALL_WRAPPER + $(INSTALL) -D -m 0755 package/vala/vala-wrapper \ + $(HOST_DIR)/usr/bin/vala + $(INSTALL) -D -m 0755 package/vala/vala-wrapper \ + $(HOST_DIR)/usr/bin/valac + $(SED) 's,@VALA_VERSION@,$(VALA_VERSION_MAJOR),' \ + $(HOST_DIR)/usr/bin/vala + $(SED) 's,@STAGING_DIR@,$(STAGING_DIR),g' \ + $(HOST_DIR)/usr/bin/vala + $(SED) 's,@VALA_VERSION@,$(VALA_VERSION_MAJOR),' \ + $(HOST_DIR)/usr/bin/valac + $(SED) 's,@STAGING_DIR@,$(STAGING_DIR),g' \ + $(HOST_DIR)/usr/bin/valac +endef +HOST_VALA_POST_INSTALL_HOOKS += HOST_VALA_INSTALL_WRAPPER + $(eval $(host-autotools-package))
vala/valac can use gir and vapi data files installed by other packages, but since these are normally installed to staging and host-vala looks for them in the host directory (logically) this leads to failure. So wrap them to call the real tool and add this information via command-line parameters to them. This is required for libgee-granite vala-in-vala bindings. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> --- package/vala/vala-wrapper | 2 ++ package/vala/vala.mk | 18 ++++++++++++++++++ 2 files changed, 20 insertions(+) create mode 100644 package/vala/vala-wrapper