Re: multiple prerequisites in pattern rules

[Noel Yap]

"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.