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

[Michael Wild]

On 6. May, 2010, at 16:15 , Jed Brown wrote:

> 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

Looking at the manpage, it seems that CMake will need a Tupfile in every directory that is to contain object files:

>> The input files can be anywhere else in the tup hierarchy, but the output file(s) must be written in the same directory as the Tupfile.