Each example plugin from the source code of this book has a build script that looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
The above is a perfectly good build script especially as the intended audience of the book doesn’t need to learn about build tools like Make or Maven or Ant.
tup is an interesting build tool for a number of reasons.
Particularly the fairly straightforward configuration and file monitoring
rebuilds (only on Linux). The other intriguing feature of tup is you
tup upd anywhere in your source code and it’ll build
everything that needs building, which is pretty convenient for large
source trees with multiple build targets/libraries - just like the
example plugins for this book!
So here’s my first attempt at a
1 2 3 4 5 6 7
I have a few reflections about this:
- I don’t know how environment variables work with tup. Just like Make, it has its own variables but it doesn’t appear to let any shell variables in (that’s why my full home directory is hard-coded at the top of the file).
- Each line in the Tupfile consists of
inputs |> commands |> outputswhich is very functional-like and intuitive to me. There doesn’t appear to be an easy way to have outputs that are outside your source tree because I had errors when I tried to copy the JAR into my server/plugins directory as a separate step, so I collapsed it into the previous JAR-building step.
%grefers to a glob in the input files, but alas only the first glob, so I couldn’t write a general rule for building any package regardless (like:
foreach src/*/*.java |> javac %f -d bin |> bin/%g.class). The other options for output flags include
%bwhich is the input base filename (e.g.
%Bwhich is the same without the extension (e.g.
HelloWorld). I couldn’t work out how to translate the
b. In Make you can do something like
$(source_files:%.java=bin/%.class)or similar and I can’t find an analogue in tup so far.