[M3devel] Building packages

[Hendrik Boom]

On Tue, May 15, 2012 at 10:33:12PM +0000, Jay K wrote, and hendrik reformatted:
> 
> You might as well just use something in scripts to rebuild the entire 
> system.It isn't so difficult nor takes very long.
>
> Get a working cm3 on any system.
>      cd scripts/python
>      ./boot1.py <target-such-as-I386_LINUX>

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

> That will produce a "bootstrap" archive.  Copy it to the "new" system.
> Extract it.
> Cd into it.
> Look at the top of Makefile and see if it seems reasonable (we 
> should use autoconf here).
> run make.
> That should give you a working cm3 for the new system.

just the compiler (and what it needs to work), presumably.

> Put that on path, e.g.:
>      su
>      rm -rf /usr/local/cm3

clearing out any old cm3 system completely

>      mkdir -p /usr/local/cm3/bin
>      cp cm3 /usr/local/cm3/bin

And putting the noew one where it can be executed.

>      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?

>
>  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?  Does 
it ship it?  Or place it somewhere else on the system?  Is it important 
for the already working cm3 compiler to be the same version as the one 
in the source tree being packaged?  And is there also a source package 
built?  Because the source package is what's needed for uploading to 
Debian.

>     ./make-dist.py

And this packages it from the shipped location?

> I'd really like to get to the point of:
>  extract
>    ./configure
>    make
>    make install  or make deb
>
> To make this work how people really want, we have to have a 
> C-generating backend.Or else provide binary packages for "every" 
> system, which isn't viable.  If Linux distributions took binary 
> compatibility seriously, we wouldn't have this problem.

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

Even the kernel calls aren't really guaranteed to stay the same, but 
there's a run-time library that's supposed to be used to call them.  And 
that's Unix policy, from way back in the 70's.

Binary-based distributions routinely compile the entire Linux system 
for each major release.  They do it package by package, but they do it.

I wonder how gcc does its bootstrap.  Presumably it's a package thet 
build-depends on itself, or something like that.

> They seem to 
> encourage/require rebuilds for every revision.But surely this is not 
> true, as there exist some closed source products like Adobe 
> Acrobat?

Such products try to have very few library dependencies.

> There is no such problem on Windows, nor I suspect Solaris, 
> nor hypothetically on Irix, AIX, VMS, HP-UX, Tru64, etc.

And that's been one of the major problems Microsoft has had with 
developing Windows.  When things need to change, you get legacy 
compatibility hacks like making the details of the storage 
allocation system calls depend on the name of the application 
being executed.

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.

-- hendrik