"Paul D. Smith" wrote: > How could it do that? Make isn't in the kernel; it can't watch the > system calls of another process. I guess it could so something bizarre > like run subcommands in strace and look for certain kinds of output. > Also someone suggested using LD_PRELOAD to load a shim library that > wraps open, etc. and writes out a makefile fragment. Cool stuff, but > not very portable. > > ClearCase's clearmake can do this, because ClearCase implements its own > filesystem (MVFS). So, clearmake can communicate with the MVFS kernel > module and track all accesses of files that are made through that > filesystem (basically all files that are in ClearCase). Even this > doesn't let clearmake track, for example, header files in /usr/include > because they're not in an MVFS filesystem.
Yeah, now that you went into the details, I don't see how I could've thought such a thing. > ny> Given that what you say is true, one way to fix the problem might > ny> be to break apart the rule. For example: > > ny> %.d: %.o > ny> $(MakeDependsAction) > > ny> %.o: %.C > ny> $(C++CompileAction) > > Well, if you're using the advanced autodependency creation method this > won't work, because a critical feature of that method is that make > _doesn't_ know how to build the dependency file. If it did, then when > you included the file make would try to rebuild it, then re-exec > itself. That defeats the purpose of the advanced method. That's right. I had missed that point. Maybe an added feature that would allow users to specify, on a per-target basis, non-target generated files would be nice? Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
