vala: add vala/valac wrapper

package/vala/vala.mk +7 -0

+# 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

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 at 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 at skate:~/projets/buildroot (next)$ ./output/host/usr/bin/vala pouet.vala
Hello, World
thomas at skate:~/projets/buildroot (next)$ ./output/host/usr/bin/valac pouet.vala
thomas at 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 at 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 at skate:~/projets/buildroot (next)$ ./output/host/usr/bin/valac pouet.vala
thomas at 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 ?

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.

Hi Gustavo,

Quoted 4 lines

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?

Quoted 1 line · Arnout Vandecappelle

Hi Gustavo,

Hi.

Quoted 11 lines

Quoted 4 lines

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.

Quoted 3 lines

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.

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.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hello,

Quoted 8 lines · Arnout Vandecappelle

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.

Quoted 3 lines

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.

Hello,

Quoted 11 lines · Arnout Vandecappelle

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.

Quoted 4 lines

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.

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.

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 <[email protected]>

---
 package/vala/vala-wrapper |  2 ++
 package/vala/vala.mk      | 18 ++++++++++++++++++
 2 files changed, 20 insertions(+)
 create mode 100644 package/vala/vala-wrapper

package/vala/vala-wrapper new file +0 -0

new file mode 100644
index 0000000..ea0bd09

package/vala/vala.mk +3 -0

index 56d4db3..5267f68 100644
@@ -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

package/vala/vala.mk +5 -0

+	$(SED) 's, at STAGING_DIR@,$(STAGING_DIR),g' \
+		$(HOST_DIR)/usr/bin/valac
+endef
+HOST_VALA_POST_INSTALL_HOOKS += HOST_VALA_INSTALL_WRAPPER
+
 $(eval $(host-autotools-package))

Quoted 2 lines

+#!/bin/sh
+$0- at 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?

Quoted 4 lines · Arnout Vandecappelle

Quoted 3 lines

+#!/bin/sh
+$0- at VALA_VERSION@ --vapidir=@STAGING_DIR@/usr/share/vala/vapi --girdir=@STAGING_DIR@/usr/share/gir-1.0 $@

Quoted 3 lines

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.