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

[Mike Shal]

On 5/5/10, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> On 5/5/2010 3:39 PM, Mike Shal wrote:
>
> > On Tue, May 4, 2010 at 5:47 PM, Bill Hoffman<bill.hoffman at
> > kitware.com>  wrote:
> >
> > > On 4/22/2010 3:47 PM, Gustavo Sverzut Barbieri wrote:
> > >
> > > > As we never attempted to do any sort of CMake generator, not even
> > > > looking the existing, I'd like to know the expected effort to write
> > > > one for Tup from you guys. Anyone that would like to help with this
> > > > task?
> > > >
> > > >
> > >
> > > I think it would be a somewhat larger undertaking.   It may tax tup
> quite a
> > > bit.  However, CMake has a pretty good set of tests so you would know
> when
> > > it was working.
> > >
> >
> > I'm not too familiar with CMake, but I wrote tup. What part of making
> > a CMake generator do you think would tax tup?
> >
> >
>  Not sure yet, perhaps none of it.  It would have to build custom commands
> and targets.   Basically, support for code generators like
> swig/moc/lex/yacc.  I guess the auto-depend stuff in tup would work for
> C/C++, but the Fortran 90 stuff in CMake would not work.  It would be an
> interesting project.  To be honest I really did not research tup very much
> at all.  CMake is also used to build very large projects like KDE, sounds
> like tup is designed with that in mind, but it would have to handle very
> larger numbers of targets and .o files.

I've used lex and yacc with it before (or at least flex and bison),
but not the other code generators you mentioned. I also don't have any
experience with Fortran 90, so I can't speak to that. The dependency
analysis is done during the sub-program's execution based on which
files are opened for read and write - it doesn't have any domain
specific knowledge. If the file access patterns are funky, it's
possible tup won't work with it. On the plus side, I don't think you
will be able to construct a program large enough that tup won't be
able to scale to.

>
>  Would tup support the idea of building .o files with -j 5, and linking
> executables with -j 2 say?  Some targets are more expensive than others, and
> you want to limit parallelism sometimes.   Note, the makefiles in CMake do
> NOT do this now, it would be a nice feature.

I don't see how this could be done without some domain specific
knowledge, or by adding this info manually into the build
configuration. I would think the optimal values would also vary widely
for different users based on their particular machines. One advantage
of tup here is that incremental builds are always accurate, so you
don't need to keep running clean re-builds. The parallelism is still
available for when you change a well-used header file (for example),
but in general I've found it to be less useful feature overall as
compared to make.

-Mike