Tricks for porting a large software project to tup build system

Question

What is the best way to port a software project with thousands of .cpp files and associated headers in a fairly well structured source tree to the tup build system?

If the tree looks like:

colors/                                                                            
 primaries/
  red.cpp 
  green.cpp
  blue.cpp
 fruity/
  orange.cpp
  grape.cpp
 grayscale/
  white.cpp
  gray.cpp
  black.cpp
some/annoying/nesting/animals/
    horse.cpp
    bear.cpp

for tens of categories with tens of target files in each, it really seems like a rather inelegant solution to write one-time use shell scripts to dump out Tupfiles in each directory, even if they are ~mostly similar thanks to sharing a Tuprules.tup. What is the right, "best practice", hopefully portable way to do build projects like this with tup?

I realize that build systems with imperative config files, i.e. scons and CMake excel at this sort of task, but I'm pretty much sold on tup due to it's many virtues. — Andrew Wagner, Nov 15 '12 at 22:46

score 2 · Answer 1 · answered Nov 14 '13 at 11:57

With the recent addition of (still not well documented) LUA parser you can avoid having one Tupfile per directory. Take a look here http://gittup.org/tup/lua_parser.html read about Tupdefault.lua

Additionally - with recent change that allows output files in DIFFERENT folder you can simlify that even more. You can compile the files "somewhere", adding them to a global group(s), and then - when you need it, link/archive them all.

Simple Tuprules.tup:

TOP = $(TUP_CWD)
!cc = |> gcc $(CFLAGS) -c %f -o %o |> %B.o $(TOP)/<objects>

Simple Tupfile just for compilation (generic one, without modification to flags or sth):

include_rules

: foreach *.c |> !cc |>

Simple Tupfile for compilation and final linking (notes as above):

include_rules

: foreach *.c |> !cc |>
: $(TOP)/<objects> |> gcc %<objects> -o %o |> application.exe

Unfortunately I don't (yet) know how to use this particular feature (global groups) with LUA parser. I even asked about that on tup-users mailing list.

score 0 · Answer 2 · answered Nov 15 '12 at 22:43

From the tup manpage, tup supports running an external shell script:

      run ./script args
          Runs an external script with the given arguments to generate
          :-rules. This is an advanced feature that can be used when the
          standard Tupfile syntax is too simplistic for a complex program.
          The script is expected to write the :-rules to stdout. No other
          Tupfile commands are allowed - for example, the script cannot
          create $-variables or !-macros, but it can output :-rules that use
          those features. As a simple example, consider if a command must be
          executed 5 times, but there are no input files to use tup's
          foreach keyword. An external script called 'build.sh' could be
          written as follows:

You could trigger a script that generates he necessary tup rules, but I assume this is not portable, since you're relying on the shell.

Tricks for porting a large software project to tup build system

2 Answers2