[m-rev.] for post-commit review: fix a problem with library installation with mmc --make
Julien Fischer
jfischer at opturion.com
Wed Aug 27 13:46:14 AEST 2014
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.
Cheers,
Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20140827/a348e5c7/attachment.html>
More information about the reviews
mailing list