example tup project for vala

[Emmanuel Oga]

Hi,

I created mi first tup configuration for vala. Here it is:

https://github.com/EmmanuelOga/valatup

I tried to follow this build process:

https://live.gnome.org/Vala/Documentation/ParallelBuilds 

There's a makefile a guy created which you can use to compare:

http://pastie.org/3371822

I'm wondering if you can help me make it better. Specially this part:

https://github.com/EmmanuelOga/valatup/blob/master/src/Tupfile

I wish there was a way to set up VAPISPARAMS from the VAPISFILES.

Thanks!

[Mike Shal]

Tup doesn't have many string manipulating functions, so there isn't a
way to do it just in the Tupfile. However, you can use a wildcard for
the VAPISFILES variable rather than listing each explicitly. For the
VAPISPARAMS it is a little trickier. One thing I tried is to generate
a list of .vapi files in the windows directory, and then use a shell
script to generate the --use-fast-vapi flags when the main valac is
executed. I don't know how this will scale up to a larger project, or
one with more intricate dependencies, but maybe it will give you some
ideas to try. Feel free to write back if you run into other issues.

(See attached patch for your git repo)

-Mike

[Emmanuel Oga]

Hey, thanks for your answer!

I added your patch to the sample project:

https://github.com/EmmanuelOga/valatup/commit/f4f0937d64b9f4da7e1348c7d3e090de86f37da3

Gotta say... it is a bit complicated to handle anything "out of the normal" with Tupfiles not being turing complete :).

For reference, looks like the "de facto standard" for building projects in vala is waf. Here is a template:

http://bazaar.launchpad.net/~asabil/vala/vala-project-template.waf/files

"everybody" seems to be doing a plain "valac -C `find -name .vala` etc...", relying in the fact that valac does not write the output C files if they are the same as output files that already exist.This seems a bit inefficient to me: the only way I can think of valac knowing it shouldn't write the file again to disk is parsing the whole program, generating the C files, then comparing somehow to the written filea. With a setup like that you save the time of running gcc on the C filea on disk, but not the vala parsing time.

DISCLAIMER: take what I said with a grain of salt... I'm very new to vala and I don't really know a lot about the toolset yet.

[Emmanuel Oga]

The same thing built with ninja [1]:

https://github.com/EmmanuelOga/valaninja 

1:http://martine.github.com/ninja/

[Mike Shal]

Sounds inefficient to me as well. Maybe the projects are small enough
that people don't care about doing a find & re-parsing *.vala?

-Mike

[Mike Shal]

I applied this patch to valatup in order to wild-card object files:

diff --git a/src/Tupfile b/src/Tupfile
index aea95d2..57c13b7 100644
--- a/src/Tupfile
+++ b/src/Tupfile
@@ -15,4 +15,4 @@ VAPISPARAMS += `./gen_vapisparams.sh windows/vapilist.txt`
: foreach *.c |> !ccobj |>

# Now that all the .o files should be generated, build object file.
-: main.o windows/sync_sample_1.o windows/sync_sample_2.o |> !ccbin |> main
+: main.o windows/*.o |> !ccbin |> main

Then I was able to do the following:

$ mv sync_sample_1.vala new_sync_sample_1.vala
$ tup upd

And get a correctly built executable. (If you don't apply the patch
above, tup just reports an error because the Tupfile now refers to an
old object file, so you have to edit that to continue).

In the valaninja repo I tried the same thing:

$ mv sync_sample_1.vala new_sync_sample_1.vala
$ ninja
ninja: ERROR: 'src/windows/sync_sample_1.vala', needed by
'_obj/src/windows/sync_sample_1.vapi', missing and no known rule to
make it

So instead to get it to work I had to re-generate the vala.ninja file:

$ ./build/configure > build/vala.ninja && ninja

But if I always re-generate the vala.ninja file then it will
needlessly rebuild parts of the project (which seems like different
parts every time?). The difference here is you have to remember to run
an arbitrary command to try to get things working. In tup you just
have to edit files (Tupfiles, source files, etc) and the only command
to run is 'tup upd'.

So for me it is not so useful because it breaks my 3rd rule of build
systems -- the user must only have one way of building the project
(ie: "tup upd" or "ninja" in this case). Are there other ways to write
the ninja file so that it does the configure step automatically when
it needs to? Of course maybe you don't care about my rules, so if it
works for you then have fun with it. It would just drive me crazy :)

-Mike

[Emmanuel Oga]

That's definitely a plus point for tup.

I made an experiment to support auto-building the ninja config files when the src files change, the caveat is that it involves running ninja twice: once to generate the config, if needed, the second time to run the actual build. Not that that is a big problem, but perhaps not too elegant.

https://github.com/EmmanuelOga/valaninja/commit/d3237da7ce135d80a8dfce667c5901bb3017ceb8