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

[Peter Ross]

On Fri, Nov 11, 2005 at 10:54:16AM +1100, Zoltan Somogyi wrote:
> 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.
> 
I agree that this scheme creates .d files which are as up-to-date as the
current scheme.  The problem is that with the current scheme, the .d file used
is always one revision behind for files which have been modified.  Most
of the time this is safe because the imports or includes of the module
haven't changed, but when they do you get problems (which disappear on
the next invocation of mmake because now your .d files are consistent).

> > > - 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.
> 
In my message to mercury-users <http://tinyurl.com/9te6f> you see the
line

	include $(OBJ:.o=.myd) 

and the rule to make the .myd file, and this is how my mmake knows about
.d files (called .myd for hysterical raisons) in other directories.
Note these changes are to support this scheme of Mmakefile.

Apparently whenever gmake detects that an included file has been rebuilt
by a rule it will re-include that file, and thus even if a module has a new
import_module or include_module it will be reflected immediately in the
dependencies.

Do you agree?

Now to your scheme, I agree it is simpler, but has the problem with being 
just that little bit behind.  Is this a major problem, I don't know?  We
have lived with this for the last 13 years without major problems.

Pete
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------