[M3devel] [M3commit] CVS Update: cm3

[Tony Hosking]

The current hack is not so bad, I suppose.  I would prefer to come up  
with a solution that simply defines Process.Wait and System.Wait as  
returning a BOOLEAN indicating if the process terminated successfully  
or not.  Are there any clients of these procedures that decode the  
bits in any more detail than simply testing non-zero?

On 14 Jan 2009, at 11:09, Jay wrote:

>   > 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.edu
> To: jay.krell at cornell.edu
> Date: Wed, 14 Jan 2009 10:11:36 +1100
> CC: jkrell at elego.de; m3devel at elegosoft.com
> Subject: 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 = INTEGER
>
> Is 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 try
> building 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 what
> order 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/202bc14c/attachment-0002.html>