[Mono-list] Re: Should I fork the MonoBASIC project out of MCS?

[Kunle Odutola]

Hi Serge,

> > Exactly. But if mcs supports many languages, someone is more likely to
> want
> > to work on developing a gcc backend than if it supports just one....
>
> Sorry, but I honestly don't understand what do you mean by "backend" here?
> In traditional sense it would be a GCC backend emitting IL for any source
> language.

Sorry about the unintended confusion Serge. I meant "use GCC as a backend".
By which I mean building an IL-frontend to GCC. Of course from the
perspective of mcc/MonoBASIC, it would be a "GCC backend". A backend - to
mcs - that uses GCC.

> But it seems that neither MCS nor MonoBASIC not designed to act as a
> "frontend" for GCC. They are Reflection based compilers.
>
> Or do you mean GCC frontend to accept IL (and translate it to native code
> with existing backends), in this case it doesn't matter how that IL was
> emmited - by standalone compiler or compiler suite, and there are already
> many compilers emmiting IL.
> Also if I understand correctly, it is not possible to use GCC's own IR
> _outside_ of GCC, so MCS emmiting RTL is not an option either.
>
> BTW, from a end-user point of view I'd prefer more lightweight standalone
> compilers, more than compiler suites.

Why exactly?. What would be the difference?.

> Also, isn't it very easy to share code between .NET programs? I mean if
> there is some common functionality between compilers (of course, there is)
> why not share it in "component" way, instead of integrating?

I see you're already thinking up creative ways to re-architect and package
the compilers - given their substantial shared functionality - rather than
than simply forking them as Miguel proposed  ;-)

We might end up with mcs.exe and mbas.exe and jcs.exe and mvb.exe etc. that
are just drivers for an hypothetical monoparser.dll component....

Kunle