[M3devel] two questions on bootstrapping the compiler

[Jay K]

m3stalonebak I think is never used, agreed.
m3bundle I don't remember why I put it there.
 
 
  Probably because in upgrade.sh or such, there was logic like if m3bundle not found in path, build it fairly early. Something like that. A lot of this is based on what the *.sh files did/do, though there is also divergence/improvement/regression.
  - The *.sh files accept additional cm3 parameters, *.py not yet.
  - The *.sh files read pkginfo.txt, which I was a vocal proponent of and implemented mostly. The *.py not yet (yeah yeah, I'm a hypocrite.)
(*.py is still arguably better than the older *.sh here, in that the data drivenness of it has less redundancy, e.g. the ordering is only present once).
 
 
import-libs is "self filtering", building it does nothing, successfully, for other targets.
 
 
Agreed.
There is are unavoidable circularities.
 
 
Historically there was also a problem with adding new targets.
If libm3 "knew" about a different list of targets than cm3, then cm3 couldn't build it. Maybe similar with m3core but I think not.
So you had to avoid using your pre-existing cm3 to build a current libm3.
First build cm3, then libm3.
That problem is gone now.
What libm3 actually I think "knew" about was more like the hash ("fingerprint") of an enum that listed all targets, which is about the same as having an exact list (few collisions that aren't also exact matches). Anyway, the list is gone.
 
 
But the circularities are and still can be present.
m3core/libm3 use LONGINT for example, so a sufficiently old cm3 can't compile them.
 
 
This is the nature of writing a system in itself.
Definitely a worthwhile tradeoff.
:)
 
 
 - Jay




________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 12 Jan 2010 21:30:49 -0500
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] two questions on bootstrapping the compiler
>
>
>
> On 12 Jan 2010, at 21:23, Coleburn, Randy wrote:
>
> Ok, I thought I understood this, but now I’m not sure.
>
> I had trouble rebuilding everything due to the recent changes. So, I ran Jay’s upgrade.py to see what it does.
>
> I find that upgrade.py does some housekeeping with the CFGs, then builds and ships the following 11 packages:
> package C:\cm3\Sandbox\m3-win\import-libs
> package C:\cm3\Sandbox\m3-libs\sysutils
> package C:\cm3\Sandbox\m3-sys\m3middle
> package C:\cm3\Sandbox\m3-sys\m3objfile
> package C:\cm3\Sandbox\m3-sys\m3linker
> package C:\cm3\Sandbox\m3-sys\m3back
> package C:\cm3\Sandbox\m3-sys\m3staloneback
> package C:\cm3\Sandbox\m3-sys\m3front
> package C:\cm3\Sandbox\m3-sys\m3quake
> package C:\cm3\Sandbox\m3-sys\cm3
> package C:\cm3\Sandbox\m3-tools\m3bundle
>
> Note that “m3staloneback” and “m3bundle” are not listed as being part of the “front” group in pkginfo.txt.
>
> Next, upgrade.py does some more housekeeping, then builds and ships the following 14 packages:
> package C:\cm3\Sandbox\m3-win\import-libs
> package C:\cm3\Sandbox\m3-libs\m3core
> package C:\cm3\Sandbox\m3-libs\libm3
> package C:\cm3\Sandbox\m3-libs\sysutils
> package C:\cm3\Sandbox\m3-sys\m3middle
> package C:\cm3\Sandbox\m3-sys\m3objfile
> package C:\cm3\Sandbox\m3-sys\m3linker
> package C:\cm3\Sandbox\m3-sys\m3back
> package C:\cm3\Sandbox\m3-sys\m3staloneback
> package C:\cm3\Sandbox\m3-sys\m3front
> package C:\cm3\Sandbox\m3-sys\m3quake
> package C:\cm3\Sandbox\m3-sys\cm3
> package C:\cm3\Sandbox\m3-tools\m3bundle
> package C:\cm3\Sandbox\m3-sys\mklib
>
> The difference here is that “m3core” and “libm3” (which are in the “front” group) are added back to the list.
>
> Q1: So, am I to infer that in the process of “bootstrapping” a new compiler using an old one, that you have to leave out “m3core” and “libm3” on the first pass, or is there some other logic going on here?
>
> It has to do with bootstrapping the compiler to implement feature FOO. Suppose that FOO is implemented in a new version of the compiler, and you also want to use it in the language libraries. First you build a compiler that can compiler FOO (using the old libraries). Then you make the FOO change to the libraries, and recompile the compiler against the new libraries. Now both libraries and compiler are FOO-capable. Carry on...
>
> Q2: Next, if “m3staloneback” and “m3bundle” are needed, shouldn’t they be listed as part of the “front” group in pkginfo.txt?
>
> They aren't actually needed here. Not sure why they are included. Nor is import-libs unless on Windows perhaps.
>
>
> Regards,
> Randy Coleburn
>
>