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