[CMake] Effort to create a new generator (tup)

Jed Brown jed at 59A2.org
Thu May 6 10:15:58 EDT 2010


On Thu, 06 May 2010 09:10:51 -0400, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> OK, so aside from the fortran depend stuff being moved to generate time. 
>   I think the remaining questions are these:
> 
> How would a large tup system be organized? Would there be a tup file for
> each target? Would there be one huge tup file for the whole project?

So the current state is that tup always builds everything.  If you're
maintaining your own system, then it would probably look like the build
files for tup itself

/Tuprules.tup   # mostly just defines build variables
  CC = gcc
  CFLAGS = -g -Wall -pipe
  !cc = |> ^ CC %f^ $(CC) -c %f -o %o $(CFLAGS) |>
  !ld = |> ^ LINK %o^ $(CC) %f -o %o $(LDFLAGS) |>
  !ar = |> ^ AR %o^ ar crs %o %f |>

/Tupfile        # top-level targets
  include_rules
  : foreach *.c |> !cc |> %B.o
  : main.o foo/libfoo.a bar/libbar.a |> ^ LINK $(CC) -o %o %f $(LDFLAGS) |> someapp

/foo/Tupfile    # builds the foo library
  include_rules
  : foreach *.c $(SRCS) |> !cc |> %B.o
  : *.o |> !ar |> libfoo.a

Of course you could flatten the hierarchy as much or as little as you
like.  For the syntax description, see

  http://gittup.org/tup/examples.html


I don't know if Tup offers a way to propagate variables upwards, this is
certainly useful when maintaining your own build files, though not
necessary with CMake.

Jed


More information about the CMake mailing list