[m-rev.] for post-commit review: fix a problem with library installation with mmc --make

[Paul Bone]

On Wed, Aug 27, 2014 at 01:46:14PM +1000, Julien Fischer wrote:
> On Wed, Aug 27, 2014 at 1:39 PM, Paul Bone <paul at bone.id.au> wrote:
> 
> > On Tue, Aug 26, 2014 at 12:23:46AM +1000, Julien Fischer wrote:
> > >
> > > When the option "--grade java" is processed the target language will be
> > set to
> > > Java, but because of the XXX in convert_grade_option/3, the target
> > language
> > > will not be set to C when the option "--grade hlc.par.gc" is subsequently
> > > processed, hence the compiler will attempt to install the library in the
> > > non-existent grade java.par.  (Since --target java implies automatic GC,
> > > the .gc component will vanish.)
> > >
> >
> > Will this problem come up again if we add different language backends to
> > the
> > low level backend?  Such as LLVM?
> 
> 
> No.  The issue was that some individual base grade components, for example
> "hlc" and "hl", were overloaded w.r.t to target language.  The right thing
> to do IMO
> is have a one-to-one mapping from base grade component -> target language.
> 
> We would add a new base grade component for an LLDS->LLVM backend, not
> re-use "asm_fast" or "reg"  for it.
> 
> As I mentioned at the top of this mail I am going to remove support for
> having
> multiple target language per base grade component anyway, so in future, it
> won't
> be able to happen.
> 

Ah, I was confusing "base grade component" with "compiler backend".

Thanks.


-- 
Paul Bone