Re: Bug#132885: ITP: mcs -- C# compiler
> > Mono (mint, the jit compiler, classes, and metadata) would go into main.
> > mcs (the compiler which depends on a c# compiler) would go into contrib.
>
> Note that the jit and mint depend on the classes and the classes, too are
> built with non-free sw. Actually, while I'm confident mcs will be
> compiled on linux pretty soon, the classes are a harder problem and will
> take longer.
>
Hehe, right now I'm tweaking genwrapper.pl to get cvs to build. (cant find
glib.h as it appears the includes from gcc aren't making it into the perl
script)
I'm not planning on uploading any Debian packages until there is an actual
release. I will provide some experimental deb packages built from CVS but
wont upload them to Debian.
> > My interpretation is that mcs is free software that depends on non-free
> > software. Eventually I hope this will change but for now thats my
> > interpretation.
>
> Well, mcs depend on free sw, but that free sw still has bugs :-)
> The current free classes are capable enough that you can compile simple
> programs with mcs on linux.
I was a little worried about this when I sent the ITP. I figured that this
would be an issue that would take care of itself, and wanted to delay any
flamewars about it. In the end it really hasn't been an issue so my concerns
were unfounded.
> Anyway, I think it's not a big problem if the packages go into contrib
> until mcs and the classes can be compiled with a bootstrapped mcs
> on the target system:
>
> csc compiles mcs to mcs1
> mcs1 compiles mcs to mcs2
> mcs2 compiles mcs to mcs3
>
> mcs3 compiles corlib to corlib1
> mcs3 compiles corlib to corlib2 (using corlib1)
> mcs3 compiles mcs to mcs4 (using corlib2)
>
> mcs4 and corlib2 ship as mcs and corlib in the tarball
>
> At this point on linux you'll just use the included mcs and corlib
> to compile them again.
> We have a few steps more than gcc because we have to compile corlib,
> too.
Cant wait.
Cheers,
Eric
Reply to: