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

[Jed Brown]

On Thu, 06 May 2010 08:28:34 -0400, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> The problem with fortran 90, is that you have to find out the depends to 
> figure out the order in which files are built.   It has a system where 
> "include like" files are generated by the compiler.  So, if you have:
> 
> a.f90 -> produces a.mod
> b.f90 -> uses a.mod
> 
> If you compile b before a, then it fails to compile.  To solve this 
> CMake's dependency code parses all the f90 files in a target first, then 
> creates depend information so that b.f90 will depend on a.f90.  I 
> suppose this part could be pushed to the generator time for the tup 
> generator.  It might make for a slow generate step in the CMake process.

Good point.  Once the *.mod files exist, tup will know about the
dependency (because the compiler looks at the *.mod file), but it
wouldn't know about it a priori (unless CMake told it, but make has the
same issue---worse due to no internal dependency knowledge).

> As far as the scalability, are there any studies that have been done 
> with larger numbers of files?  On way to find out would be to create the 
> generator.

Presumably you've looked at these?

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

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

I can confirm essentially the same scalability on an independent test
using the setup scripts from

  http://retropaganda.info/~bohan/work/sf/psycle/branches/bohan/wonderbuild/benchmarks/time.xml

Note that the do-nothing dependency analysis for the largest test cases
takes way under 10 milliseconds.  I would be surprised if a do-nothing
rebuild of all of KDE exceeded 10 ms, and the single-file (header or
source) case should also be under one second (acknowledging that this
might trigger lots of relinking, but that's not a build-system
scalability issue).

Jed