[M3devel] [M3commit] CVS Update: cm3

[Jay]

  > Sounds like your upgrade script
 
Based on someone else's upgrade.sh.
 
 
 > The alternative is to fold sysutils into m3core, where it can be used directly
 
  Merging sysutils into m3core doesn't quite work,    again only or due to bootstrapping from older builds.  
  The compiler uses sysutils. Older builds don't have it at all,    and can't build m3core...but maybe again, make that hand patch    Long.Rep = INTEGER? Or have an up to date compiler.      Pointless statement I'm making though, it devolves to:          - have an up to date m3core in bootstrap       - or have sysutils in bootstrap, which implies up to date m3core       - or merge sysutils with m3core, which implies up to date m3core (and the second)   
   => "have an up to date m3core" (and LONGINT capable compiler)  
 
And I think merging them is a fine idea.
I generally like fewer larger pieces of reusable code, though
the counterpoint is to have more smaller independently changable pieces.
 
 Probably the scripts and/or m3makefiles should probe the compiler version  and/or m3core version and/or sysutils presence and error clearly if it is too old/absent. 
 Possibly some "feature detection" feature is needed. 
 The compiler can just define Quake variables willy/nilly.   if defined("HAS_LONGINT")  
 Less clear how to probe m3core capability.    Can try compiling a little program against the old WaitProcess signature.    I'm leary of anything that resembles autoconf though (though I have autoconf-ish   stuff in my config files already, probing some cm3cg and cm3 behavior). 
  Oh...I looked at WaitProcess history. It looks like I introduced it, in 2008.   So..while it never returned the full status word, there also wasn't much history    to change. 
  Compiler could expose m3core functionality via variables too, though that..is wrong.   It could only expose the m3core it is linked to, not the one it is building.   I guess the only way really is to define a version or date constant and folks    can write constant expressions based on it, though that doesn't get you very far.
 Less clear how to correctly probe for package existance.  Easy to do ad-hoc by probing package store files, not sure what is the right way. 
 
 
  I also want to try this "import_pkg" directive I see in the docs. It might help a lot here,  if I understand it, and if it actually exists and resembles the doc I read.
  It sounds like it recompiles a package's source as part of another package, statically
   linking it. It would be bloating in the absence of build_standalone(), but not in its presence. 
 
 
 > No!  I did not want to do have this hack 
 Are the hacks this time in sysutils really so bad? m3core is left unadulterated. sysutils assumes waitpid(0) won't deadlock, which is true of kernel threads and cm3's use.
  - Jay



From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 10:11:36 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3


On 14 Jan 2009, at 01:54, Jay wrote:


 > fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGERIs that what bootstrapping should do? Automate that little patch for the first pass and undo it in the second? Then always building in dependency order?

I would prefer to get all the bootstrap archives LONGINT-capable.  Just do the patch by hand to build the initial archives and then forget about it.

Tonight I was trying to build from PPC_DARWIN 5.5.0.I figured, heck, maybe it supports LONGINT already, maybe I should just trybuilding up in dependency order.But then I hit the problem of Compiler.i3 mismatch due to new targets.


So...is that correct?Does building in dependency order predictably fail if compiler has fewer targets than runtime?But starting with existing m3core/libm3 and first building the compiler against them predictably works?

Yes, it works.

I've added targets a bunch and usually don't have a problem, but I can't say for certain whatorder I do things when I do this.Certainly "upgrade.py skipgcc" is something I run fairly often.It is very fast on NT386 (and unlike upgrade.sh, it doesn't build all of std).

Sounds like your upgrade script

For now I put in two small hacks to sysutils, so it works with old m3core.

No!  I did not want to do have this hack.  Let's just fix the boot archives to handle new m3core and have sysutils work as expected.  The alternative is to fold sysutils into m3core, where it can be used directly.  That might be a better solution given the dependency.  Thoughts?



















 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090114/3415ad8f/attachment-0002.html>