[M3devel] pruning m3cc/gcc?

[Jay]

Ok, presumably then ok to prune it just partly, like intl, libssp, libmudflap, libgomp, treelang, beyond that (fixincludes, libgcc) would require some checking/testing. Might even be worthwhile to "simplify" the m3makefile and reach a compromise that works only by some deletion.
Really I wish somehow gmp/mpfr built more quickly. I often delete their source locally but can't commit that.
 
 - Jay

________________________________
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Mon, 29 Jun 2009 09:41:09 -0400
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] pruning m3cc/gcc?
>
> I personally like having the ability to build C from the same source tree. It's useful for debugging the backend sometimes (looking at the equivalent code generated from C).
>
> On 28 Jun 2009, at 23:38, Jay wrote:
>
>
> I keep thinking of deleting
>
> m3-sys/m3cc/gcc/intl
> m3-sys/m3cc/gcc/libgomp
> m3-sys/m3cc/gcc/libmudflap
> m3-sys/m3cc/gcc/libssp
> m3-sys/m3cc/gcc/fixincludes
> m3-sys/m3cc/gcc/libgcc
>
>
> We don't use any of it.
> Some of these deletions would shorten our build command lines.
> Though some (esp. fixincludes and maybe libgcc) might break the
> shortest configure + make that the "real" cm3 doesn't use but can be useful.
>
>
> I didn't include them in gcc-interix and gcc-apple.
>
>
> But there are two possible contradictory goals:
>
>
> - just have what we use/change
> - have a complete merged gcc tree from which you
> could build gcc/cc1 and not just cm3cg
> Except we don't have C++, Java, Ada, Fortran,
> so we don't really have this, but C probably counts for something.
>
>
> If the second is the goal, don't delete.
> If the first is the goal, delete.
>
>
> There is also "having it all there in case it is needed
> or somesuch", but that's easy enough to get elsewhere.
>
>
> - Jay
>