<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
[inline, maybe to myself in places out of ambiguity]<br><br><br><div>> So any cm3 system is capable of creating a bootstrap archive for any other cm3 system<br><br><br> Yes. Except you need Cygwin on NT to cross to non-NT.<br><br><br>> > That should give you a working cm3 for the new system.<br>> <br>> just the compiler (and what it needs to work), presumably.<br><br><br>Yes. But not the backend. Ok.<br>That gets built later on the target system.<br><br> <br> > > rm -rf /usr/local/cm3 <br> > <br> > clearing out any old cm3 system completely <br><br><br> Correct. Or pick another location. <br><br><br>> > mkdir -p /usr/local/cm3/bin<br>> > cp cm3 /usr/local/cm3/bin<br>> <br>> And putting the noew one where it can be executed.<br><br><br>Correct. Or pick another location.<br><br><br>> > exit<br>> > PATH=/usr/local/cm3/bin:$PATH<br>> <br>> And this then builds everything, and makes a .deb<br>> <br>> > cd to scripts/python in the source tree on the new system.<br>> > Then run ./boot2.sh<br>> > Then ./make-dist.py.<br>> > That should give you the entire system newly built, and a .deb.<br>> <br>> I recal there are a few place in the Modula 3 build p[rocess where it <br>> requires other resources to already exit (the data base stuff is one I <br>> recall). If they are not available, will the process fail, or will if <br>> just build an incomplete .deb?<br><br><br><br>Good point. In the scripts directory, you can always safely remove PKGSDB<br>and it will be recreated. It goes out of date occasionally. I've been meaning<br>to make that automatic by putting a version and/or date in it or such.<br><br><br>> ><br>> > If you already have a working cm3 on the system you want to run it on<br>> <br>> Which is what I've got on my two machines, so this is what I'll be <br>> trying.<br>> <br>> > cd scripts/python<br>> > ./upgrade.py<br>> <br>> this script recompiles everything from the complete source tree?<br><br><br>I think so. It might only build the compiler.<br>There is ./do-cm3-all.py if unsure.<br><br><br>> Does it ship it?<br><br><br>Yes<br><br>.<br> > Is it important for the already working cm3 compiler to be the same version as the one <br> > in the source tree being packaged?<br><br><br> Definitely not. This is how we upgrade from old to new. Or possibly new to told.<br><br><br> > And is there also a source package built?<br><br><br> No. It would be C code anyway, so not source from most people's point of view.<br><br> <br>> Because the source package is what's needed for uploading to <br>> Debian.<br><br><br>They wouldn't like it anyway.<br> What do they do with stuff written in Haskell, C#, etc.?<br><br><br>> <br>> > ./make-dist.py<br>> <br>> And this packages it from the shipped location?<br><br><br>I think it builds it from scratch. Read it?<br><br><br>> That is. apparently, deliberate policy. Linux aims for source-code <br>> compatibility.<br><br><br>Very lame.<br><br><br>> I wonder how gcc does its bootstrap.<br><br><br>Right, relevant question.<br><br><br>> Such products try to have very few library dependencies.<br><br><br>As do we..but we do have optional GUI..<br><br><br>> And that's been one of the major problems Microsoft has had with <br><br><br>It is not that difficult and it is worth it.<br>The Linux/BSD folks break things seemingly gratuitously.<br><br><br>> compatibility hacks like making the details of the storage <br>> allocation system calls depend on the name of the application <br>> being executed.<br><br><br>It doesn't work quite that way.<br>There is an appcompat database that checks things like name and version and yes changes the heap allocator.<br>Just recompiling the relevant buggy third party code wouldn't make it work either.<br>There is code out there that uses freed memory or uses memory past the allocation or double frees (same as using freed memory)<br>Heap implementations are always necessarily at least somewhat lenient, and then once you<br>are lenient a certain amount or in a certain way, you are stuck.<br><br><br>This isn't source compatibility. It is overly precise behavioral compatibility the likes of which very few<br>programmers would advocate, but which is necessary in a system with so many applications.<br><br><br>There are security aspects too, like if the stack should be executable.<br>Again though, this is precise behavior compatibility. Just recompiling the code wouldn't fix it.<br><br><br>> It also enables and encourages third-party developers to distribute <br>> application in binary only, making source code inavailable. And that in <br>> turn makes it necessary to remain long-term compatible with ancient <br>> bugs.<br><br><br>The bugs are in the third party code and you'd have to change a lot of third party source<br>to keep it working..<br><br><br>The trade off is a more active (at least historically) third party software market.<br><br><br>Anyway, please try out the various scripts until you get it working.<br>Then we can document it and make it better.<br>Perhaps the goal should ship only bootstrap packages for the next release?<br>Make everyone here experience them and approve them?<br>Autoconf-ize them a bit?<br>Or verify they work well enough and worry about it if they ever stop working?<br>(Autoconf is sometimes overkill.)<br><br><br><br>It'd be nice if the assembly code wasn't e.g. Linux-specific but only x86-specific.<br>We could maybe blow up the jmpbuf size per-architectures instead of per architecture+kernel?<br>Maybe.<br><br><br><br><br> - Jay<br></div> </div></body>
</html>