<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
[old, was going through mail for another reason]<br><br>btw, treelang is gone in later gcc releases, e.g. 4.5.<br>I think I read they didn't want to maintain it any longer.<br><br> - Jay<br><br><br>> From: hosking@cs.purdue.edu<br>> To: jay.krell@cornell.edu<br>> Date: Mon, 29 Jun 2009 12:01:16 -0400<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] pruning m3cc/gcc?<br>> <br>> Please leave treelang. It is a good model for building gcc IR trees <br>> as done by cm3cg.<br>> <br>> On 29 Jun 2009, at 10:42, Jay wrote:<br>> <br>> ><br>> > Ok, presumably then ok to prune it just partly, like intl, libssp, <br>> > libmudflap, libgomp, treelang, beyond that (fixincludes, libgcc) <br>> > would require some checking/testing. Might even be worthwhile to <br>> > "simplify" the m3makefile and reach a compromise that works only by <br>> > some deletion.<br>> > Really I wish somehow gmp/mpfr built more quickly. I often delete <br>> > their source locally but can't commit that.<br>> ><br>> > - Jay<br>> ><br>> > ________________________________<br>> >> From: hosking@cs.purdue.edu<br>> >> To: jay.krell@cornell.edu<br>> >> Date: Mon, 29 Jun 2009 09:41:09 -0400<br>> >> CC: m3devel@elegosoft.com<br>> >> Subject: Re: [M3devel] pruning m3cc/gcc?<br>> >><br>> >> I personally like having the ability to build C from the same <br>> >> source tree. It's useful for debugging the backend sometimes <br>> >> (looking at the equivalent code generated from C).<br>> >><br>> >> On 28 Jun 2009, at 23:38, Jay wrote:<br>> >><br>> >><br>> >> I keep thinking of deleting<br>> >><br>> >> m3-sys/m3cc/gcc/intl<br>> >> m3-sys/m3cc/gcc/libgomp<br>> >> m3-sys/m3cc/gcc/libmudflap<br>> >> m3-sys/m3cc/gcc/libssp<br>> >> m3-sys/m3cc/gcc/fixincludes<br>> >> m3-sys/m3cc/gcc/libgcc<br>> >><br>> >><br>> >> We don't use any of it.<br>> >> Some of these deletions would shorten our build command lines.<br>> >> Though some (esp. fixincludes and maybe libgcc) might break the<br>> >> shortest configure + make that the "real" cm3 doesn't use but can <br>> >> be useful.<br>> >><br>> >><br>> >> I didn't include them in gcc-interix and gcc-apple.<br>> >><br>> >><br>> >> But there are two possible contradictory goals:<br>> >><br>> >><br>> >> - just have what we use/change<br>> >> - have a complete merged gcc tree from which you<br>> >> could build gcc/cc1 and not just cm3cg<br>> >> Except we don't have C++, Java, Ada, Fortran,<br>> >> so we don't really have this, but C probably counts for something.<br>> >><br>> >><br>> >> If the second is the goal, don't delete.<br>> >> If the first is the goal, delete.<br>> >><br>> >><br>> >> There is also "having it all there in case it is needed<br>> >> or somesuch", but that's easy enough to get elsewhere.<br>> >><br>> >><br>> >> - Jay<br>> >><br>> <br> </body>
</html>