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

[Mike Shal]

On 5/7/10, Michael Wild <themiwi at gmail.com> wrote:
>
>  On 6. May, 2010, at 18:59 , Jed Brown wrote:
>
>  > On Thu, 6 May 2010 18:16:14 +0200, Michael Wild <themiwi at gmail.com> wrote:
>  >>
>  >> Another issue: How would one automatically rerun CMake when one of the
>  >> input files to CMake changes? Of course, the build would then have to
>  >> continue with the potentially modified Tupfile's...
>  >
>  > Rebuilding with modified Tupfiles is not a problem, and will only build
>  > what is necessary.  But:
>  >
>  >  Tup doesn't support generating the Tupfiles themselves from other
>  >  programs. If you do that, you would need to run a separate program to
>  >  generate them before running 'tup upd'. I would hope that tup is
>  >  expressive enough that you don't feel the need to generate the
>  >  Tupfiles, though.
>  >
>  >  http://groups.google.com/group/tup-users/msg/2b16ad647bda6c7c
>  >
>  >
>  > Maybe this will change, preferably by coming up with a clean way to
>  > express the dependency.
>  >
>  > Jed
>
>
> So far it seems that tup just isn't suited to be used by build-system generators such as CMake. Also, the crazy LD_PRELOAD stuff going on in there gives me the heebie-jeebies. There are plenty of ways that tup could miss an automatic dependency (such as a program setting LD_PRELOAD itself before using system/exec*/ or similar). What happens if somebody uses distcc?

Possibly not. I don't see why having the build system check that the
program actually accesses the files as claimed in the build
description should be a problem. LD_PRELOAD may not be the best
method, but it is nice not to have to worry if you miss a dependency
(since you'll get an error message). I think this is better than
standard make, which may just silently work in such cases, and give
you problems with future clean or parallel builds. Maybe with CMake
you don't have these issues.

-Mike