[m-rev.] diff: fix sub-module build problem

Peter Ross peter.ross at miscrit.be
Fri Nov 16 02:40:28 AEDT 2001


On Fri, Nov 16, 2001 at 02:19:04AM +1100, Simon Taylor wrote:
> On 15-Nov-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > Estimated hours taken: 1
> > Branches: main
> > 
> > When compiling a module which contains a nested sub-module you must
> > build the .int0 file before attempting to build the .int file.  This is
> > because while building the .int file you will need the .int0 file to
> > build the .int file of the nested sub-module.
> > 
> > compiler/modules.m:
> >     When generating the .d file for a nested submodule.  Add the rule
> >         <sourcefilename>.date : <sourcefilename>.int0
> >     where <sourcefilename> is the name of the sourcefile which contains
> >     the nested sub-module.
> 
> > Index: compiler/modules.m
> > ===================================================================
> > @@ -1885,7 +1885,9 @@
> >  			string__remove_suffix(SourceFileName, ".m",
> >  				SourceFileBase)
> >  		->
> > -			string__append(SourceFileBase, ".err", ErrFileName)
> > +			ErrFileName = SourceFileBase ++ ".err",
> > +			SourceDate = SourceFileBase ++ ".date",
> > +			SourceInt0 = SourceFileBase ++ ".int0"
> >  		;
> >  			error("modules.m: source file doesn't end in `.m'")
> 
> What about `--use-subdirs'?
> Also, there isn't guaranteed to be a <sourcefilename>.int0.
> For example, in the browser directory, parse.m contains the
> module mdb.parse. If that module contained sub-modules,
> the generated `.int0' file would be `mdb.parse.int0',
> not `parse.int0'.
> 
> > @@ -2224,6 +2226,7 @@
> >  			%
> >  			io__write_strings(DepStream, [
> >  				"\n",
> > +				SourceDate, " : ", SourceInt0, "\n",
> >  				Date0FileName, " : ", SourceFileName, "\n",
> >  				"\t$(MCPI) $(ALL_MCPIFLAGS) $<\n",
> >  				DateFileName, " : ", SourceFileName, "\n",
> 
> 
> This code is in the `then' part of an if-then-else with condition:
> 	( { SourceFileName \= ExpectedSourceFileName } ->
> 
> That isn't a correct way to work out whether a module
> is a nested sub-module. That condition will succeed
> for browser/parse.m, which isn't a nested sub-module.
> 
> I'd suggest leaving this change for now. My `mmc --make'
> change will add some things to the `module_imports' type
> which should make implementing this change a bit easier.
> 
Since you will understand the changes you have made, I assume it will be
reasonably easy for you to add the correct code.  I assume that you
understand the problem that I am trying to fix.  Would that be possible?

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



More information about the reviews mailing list