[M3devel] Building packages

[Jay K]

[inline, maybe to myself in places out of ambiguity]


> So any cm3 system is capable of creating a bootstrap archive for any other cm3 system


 Yes. Except you need Cygwin on NT to cross to non-NT.


> > That should give you a working cm3 for the new system.
> 
> just the compiler (and what it needs to work), presumably.


Yes. But not the backend. Ok.
That gets built later on the target system.

 
  > >      rm -rf /usr/local/cm3 
  >  
  > clearing out any old cm3 system completely 


 Correct. Or pick another location. 


> >      mkdir -p /usr/local/cm3/bin
> >      cp cm3 /usr/local/cm3/bin
> 
> And putting the noew one where it can be executed.


Correct. Or pick another location.


> >      exit
> >      PATH=/usr/local/cm3/bin:$PATH
> 
> And this then builds everything, and makes a .deb
> 
> > cd to scripts/python in the source tree on the new system.
> > Then run ./boot2.sh
> > Then ./make-dist.py.
> > That should give you the entire system newly built, and a .deb.
> 
> I recal there are a few place in the Modula 3 build p[rocess where it 
> requires other resources to already exit (the data base stuff is one I 
> recall).  If they are not available, will the process fail, or will if 
> just build an incomplete .deb?



Good point. In the scripts directory, you can always safely remove PKGSDB
and it will be recreated. It goes out of date occasionally. I've been meaning
to make that automatic by putting a version and/or date in it or such.


> >
> >  If you already have a working cm3 on the system you want to run it on
> 
> Which is what I've got on my two machines, so this is what I'll be 
> trying.
> 
> >     cd scripts/python
> >     ./upgrade.py
> 
> this script recompiles everything from the complete source tree?


I think so. It might only build the compiler.
There is ./do-cm3-all.py if unsure.


> Does it ship it?


Yes

.
 >  Is it important  for the already working cm3 compiler to be the same version as the one 
 > in the source tree being packaged?


 Definitely not. This is how we upgrade from old to new. Or possibly new to told.


 >  And is there also a source package built?


 No. It would be C code anyway, so not source from most people's point of view.

 
> Because the source package is what's needed for uploading to 
> Debian.


They wouldn't like it anyway.
 What do they do with stuff written in Haskell, C#, etc.?


> 
> >     ./make-dist.py
> 
> And this packages it from the shipped location?


I think it builds it from scratch. Read it?


> That is. apparently, deliberate policy.  Linux aims for source-code 
> compatibility.


Very lame.


> I wonder how gcc does its bootstrap.


Right, relevant question.


> Such products try to have very few library dependencies.


As do we..but we do have optional GUI..


> And that's been one of the major problems Microsoft has had with 


It is not that difficult and it is worth it.
The Linux/BSD folks break things seemingly gratuitously.


> compatibility hacks like making the details of the storage 
> allocation system calls depend on the name of the application 
> being executed.


It doesn't work quite that way.
There is an appcompat database that checks things like name and version and yes changes the heap allocator.
Just recompiling the relevant buggy third party code wouldn't make it work either.
There is code out there that uses freed memory or uses memory past the allocation or double frees (same as using freed memory)
Heap implementations are always necessarily at least somewhat lenient, and then once you
are lenient a certain amount or in a certain way, you are stuck.


This isn't source compatibility. It is overly precise behavioral compatibility the likes of which very few
programmers would advocate, but which is necessary in a system with so many applications.


There are security aspects too, like if the stack should be executable.
Again though, this is precise behavior compatibility. Just recompiling the code wouldn't fix it.


> It also enables and encourages third-party developers to distribute 
> application in binary only, making source code inavailable.  And that in 
> turn makes it necessary to remain long-term compatible with ancient 
> bugs.


The bugs are in the third party code and you'd have to change a lot of third party source
to keep it working..


The trade off is a more active (at least historically) third party software market.


Anyway, please try out the various scripts until you get it working.
Then we can document it and make it better.
Perhaps the goal should ship only bootstrap packages for the next release?
Make everyone here experience them and approve them?
Autoconf-ize them a bit?
Or verify they work well enough and worry about it if they ever stop working?
(Autoconf is sometimes overkill.)



It'd be nice if the assembly code wasn't e.g. Linux-specific but only x86-specific.
We could maybe blow up the jmpbuf size per-architectures instead of per architecture+kernel?
Maybe.




 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/6eb0b9b9/attachment-0002.html>