<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>They likely aren't all used.</div><div>I'd like to make none of them used, but that is another matter.</div><div><br></div><div><br></div><div>Look in src/m3makefile.</div><div><br></div><div><br></div><div>I think OpenBSD targets might be back on gcc-4.2.</div><div>There is flexibility in there, in m3makefile and "parse.c", but maybe at too high cost.</div><div><br></div><div><br></div><div>The problem, you can imagine, is that Apple has as fork, OpenBSD has a fork, we have a fork, and there is mainline.</div><div>Ideally everyone would be in mainline and nobody would have any forks.</div><div><br></div><div><br></div><div>As we/I move from major version to version, I generally make a new fork.</div><div><br></div><div><br></div><div>I have a certain paranoia and laziness when debugging -- "does it work with the old one" -- "how easy is to reconstruct the old one? Oh, cool, it is still right there, I don't have to figure out how to go backwards in source control, and I can easily have them both side by side". I realize source control could help me here.</div><div><br></div><div><br></div><div>It also allows for "staging", i.e. I can bring in new version, test some targets, but leave the other targets alone, waiting for myself or others to test them later. Or, decide they are little enough used just move them forward w/o testing.</div><div><br></div><div><br></div><div>If gcc obsoletes targets we want to keep, we could keep the old versions. Not super useful given our usage levels.</div><div><br></div><div><br></div><div>We could maybe also minimize our changes and distribute patches only.</div><div>Sometimes maybe I went overboard with my changes.</div><div><br></div><div><br></div><div>Or we could ditch gcc entirely and use the C backend and/or LLVM, hopefully both unpatched. :)</div><div><br></div><div><br></div><div>Try xz instead of gzip, maybe it halves the size?</div><div><br></div><div><br></div><div> - Jay<br><br><br></div><div>> Date: Wed, 3 Jun 2015 13:57:38 +0200<br>> From: adacore@marino.st<br>> To: m3devel@elegosoft.com<br>> Subject: [M3devel] Are all 5 gcc branches used?<br>> <br>> I see 5 gcc branches in m3-sys/m3cc. I've seen gcc-4.7 in use and I can<br>> guess gcc-apple is still used, but are gcc, gcc-4.5, and gcc-4.6<br>> branches obsolete?<br>> <br>> There reason why it matters is that I'm using github's built-in "create<br>> tarball from top of repo" capability as the digest-confirmed source<br>> distribution file. All the extra gcc branches are causing the<br>> compressed tarball to be pretty big. Currently it's at 150Mb.<br>> <br>> If some of these gcc branches are unused and will never again be used, I<br>> might suggest they are pruned. It's in the repository so they could be<br>> retrieved with the right hash, and it would dramatically reduce the size<br>> of the archive tarball.<br>> <br>> If all 5 versions of gcc are still used then that's a horse of a<br>> different color.<br>> <br>> John<br></div> </div></body>
</html>