On Thu, 06 May 2010 09:10:51 -0400, Bill Hoffman <bill.hoff...@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 _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
