[m-rev.] for prelim review: "Recursive make considered harmful" support

[Zoltan Somogyi]

On 10-Nov-2005, Peter Ross <pro at missioncriticalit.com> wrote:
> > - Have a file in the top level directory that lists all the directories
> >   that may store .d files. When invoking mmake in that directory, include
> >   all the .d files in all these directories, not just the ones in the current
> >   directory.
> > 
> The advantage of the current scheme is that one always gets the most
> up-to-date dependencies (plus no need for mmake depend), this wouldn't
> be true of the scheme you give as you would always be one version
> behind.

That isn't true. The scheme I proposed doesn't affect the timing of the
creation of .d files at all; they are always exactly as up-to-date as
with the current scheme. A top-level mmake just knows where all the relevant
.d files are, that's all.

> > - Add a new option to mmc that specified the name of the directory into which
> >   .d files should be put. You can then set up an Mmake variable to specify
> >   the name of the top level directory in all invocations.
> > 
> For me the best solution is to extract the directory part of the
> filename to compile and place the .d file always in that directory.
> If there is not directory part then use the current directory.
> 
> eg "mmc --compile-to-c ant/a.m" and "mmc --generate-dependency-file ant/a.m" 
> both place a.d into the ant directory.

Yes, but how would an mmake in one directory know about the .d files in other
directories? Your solution doesn't address that problem.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------