[M3devel] FW: INSTALL_ROOT and PKG_USE in cm3.cfg

Fri Jan 25 16:21:26 CET 2008

This was truncated, and there is a little of value perhaps...except probably just leave all the targets alone and focus on the much less disruptive decision for how to name all the many future targets. :) and the more productive work of bringing them up (I'm thinking, after NT386GNUish stuff, of looking into PPC_{NETBSD,OPENBSD} or NBSD,OBSD. I've got the hardware and the CDs at least.. and then if I'm feeling crazy, X86_DJGPP aka X86_MSDOS or such, and then X86_SOLARIS maybe..I've got X86 and PPC32 you see, grasping at where to go...oh, and AMD64_NT, AMD64_SOLARIS does that exist? Might have to get a new machine for that, but as long as its available in laptop form factor I'm game. (AMD64_F|N|OBSD too, I wonder if AMD64_DJGPP will materialize :) oh but this takes wasting money but AMD64_DARWIN; OLPC is en route but I don't think that merits work, it's just X86_LINUX, I mean LINUXLIBC6.. :) ). No idea how far I'll get here but they are thoughts at least. And fix the Pixmap bug...

I basically below just agree with what Olaf already said -- processor-os-variant.
Variant is "random", but doing better is probably impossible, and variant is bound to be needed somewhere sometime.
And it can be empty so no harm.

 - Jay

From: jayk123 at hotmail.comTo: wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfgDate: Fri, 25 Jan 2008 15:07:20 +0000

> I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.Uh oh...[big ramble...] Darwin: I was surprised, but I understood. I know a lot of the history and I get it.I used the LINUXELF port briefly, or maybe the LINUX (a.out) one.I guess hypothetically you can still boot LINUX 1.2 on either modern hardware or VMs??????Anyone reporting 10 year uptimes?? Unix ABI: I'm surprised the compat is so bad. Microsoft does an excellent job of ABI compat, but behavioral compat is another matter. > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.I understand. I believe Aqua is mostly just a marketing term even.Apple's got a bazillion different libraries to do the same thing.Want to draw on the screen -- QuickDraw (deprecated) or CoreGraphics, OpenGL..Want to have a text editor -- TextEdit, MSLTE, and something else, and third party like "WASTE".Want to get a mouse click -- there's two event managers.Want to open a file -- there's like four or more sets of APIs -- FSSpec, FSRef, stdio, unixio, maybe something in Cocoa.Even in the kernel they have multiple frameworks I believe.It appears to be a big random mishmash.They had two APIs for LoadLibrary/GetProcAddress, and then later add dlopen.A lot of this is historical too.They have history back to the early 1980s and they have migration story after migration story after migration story, gradually breaking all existing source code and binaries, but never eveything quite at once. At this point, nothing produced before around the year 2000 can run on an Intel Mac or a PowerPC Mac running 10.5. 10.4 on PowerPC could run stuff going way way back -- 68K even. People used to have access to video memory at fixed addresses, "low memory globals" all kinds of crazy stuff. (Really, I understand -- MacOS X is 10 or Unix. I don't know how/if they are ever going to get to 11. They were up to about version 10 via gradual incrementing through the years. System 7 was a breathrough kind of in the late 80's early 90's, System 7.1ish when the PPC came out in 1994, gradually up to around 7.5, then rapidly through 8 and 9 when Jobs returned before they release Mac OS X. I know a lot here..it's annoying... We had "fat Mac" circa 1984/1985 with 512meg and two floppy drives, a 68020 Mac II, etc.If you see the movie The Firm, when lawyer/actionhero Tom Cruise uses his computer, it plays the Mac floppy disk noise.)And by breathrough, I mean it actually sucked. They had no or nearly no protected memory user/kernel split until this century. Shared library sorts of things were loaded completely into memory at boot time generally. Microsoft beat them by 5+ years, Unix beat by far more. But now it's a fairly level playing field -- everyone has about the same architecture. Except all the low end (free) Unixes seemed to take forever to admit they needed threads, and I doubt any of them scale well. I think they resisted just to avoid being like NT, waiting and waiting and finally giving in, thus some of the ABI issues, no threads, "Linux threads", and finally NPTL -- native pthreads library -- kernel threads. And just when everyone arrived at the same place, along comes web apps distributed across a cluster, too many cores per chip for anyone to schedule... [editing has ripped things away from what they related oh well...] You can have all the smarts you want about your workload and manually schedule (fibers, vtalarm threads), but you'll never likely be able to control what CPU you are on and thus you will generally lose, unless there is only one CPU. I kind of assume we (the larger we m3devel, but indeed, perhaps every pair of developers :) ) would never be able to agree on names. I think the easiest to agree to plan is to leave it alone.But, um, I agree! If we, um, could agree on a scheme and set of names, I'd go for it.I am a little more optimistic than this...but I hesitate, briefly, to suggest... The GNU folks have a system, of triples or more recently quadruples.Something like processor-'hardware'-kernel, I forget and can't look now.'hardware' seems to be 'unknown' or 'pc' a bunch, so I don't know what it is.uname seems to be the ingredients of most of this.i686-pc-cygwini686-pc-nti686-pc-linuxppc-mac-darwin?ppc-mac-classic68k-mac-classic I figure to vet the design it helps to come up with many examples, even of platforms that don't matter.Maybe even to deal with the msdos mess, could be 16bit, 286, 386.. I agree with you that a double seems to almost always suffice. If you look at the existing names (from memory), I think you can derive something like:{X86,AMD64,PPC,PPC64,ALPHA,MIPS,ARM,SH,SPARC,68K,VAX,IA64,HPPA}_{LINUX,SOLARIS,NT,OSF1,OS2,NEXT,MSDOS,VMS,Mac,OldMac,AIX,HPUX,FreeBSD,NetBSD,OpenBSD} and cover almost the whole problem. This doesn't address the elephants that seems to have finally left the room -- compiler, linker, window library, thread library, C library, modula-3 backend. Probably most platforms should be a 2-tuple but there should guidance on how to build n-tuples.?? x86-nt-msc-mslink-msgui-kthr-msvcr -- native  just call it x86-nt ?x86-nt-gcc-gld-msgui-kthr-msvcr -- mingwinx86-nt-gcc-gld-xwin-kthr-cyg -- nt386gnux86-nt-gcc-gld-xwin-pthr-cyg -- nt386gnu with pthreadsx86-linux-gcc-gld-vga-nothr-newlibx86-linux-icc-glc-nowin-nptl-glibc -- icc Intel compilerx86-linux-gcc-gcc-qtopia-uthread-glibc These names are too long. The n-tuples open up many issues, such as variables that really almost never vary given what preceds them.Linux doesn't always use gcc, but almost.Or whether or not a configuration is link compatible with another.Varying the compiler tends not to break link compatibility, that isn't automatic, it isn't free i general, but the compiler authors usually make it so. You all can see if n-tuples matter for the vast majority of platforms, but they, perhaps matter for x86-nt.But there is a big huge out of this that is in place, as I have said many times.. platform is nt386, everything else is something else, a "configuration" perhaps. Perhaps there should be a few more quake variables specced that cm3 can/should know about. Perhaps all of the target dependencies should be moved into the configuration file?????? I think there's so little, it makes little difference either way. Perhaps the notion of target drops away entire in cm3 and it's all just configuration and has less meaning?I mean..you know, what is the meaning? it's jmpbuf size, it gcc configuration, it's build_dir, those strike me as the majority of what "target" means. alignment, integer-size (always 32...except alpha), whether to use the integrated backend, and if so, a few other variables. I haven't allowed for versions -- FreeBSD4, FreeBSD5, FreeBSD6. I also think, I hate to say, you might want to account for "fat binaries".On a Mac, you can build up for four architectures into one binary.x86,AMD64,PPC,PPC64.However that really strikes at my crazy cross idea and putting in .sh files that call out to the right binary.I heard NextStep/OpenStep ran on four architectures way back when -- 68k, x86, SPARC, HPPA, not to mention the variant the x86 variant that ran in NT (with gcc). Even Win32 lets you build hybrid 16bit/32bit or 16bit/64bit binaries, since there is an "MS-DOS" stub. This is why, of course, you end up with ad-hoc names. Because the extra variables are usually missing, and they vary differently depending on context, so just make up something. Perhaps you use the doubles I gave, and then you are allowed to append a dash and an arbitrary extra string.Oh, sorry, you already said that. You called it "variant". I guess that's it. {x86,AMD64,...}_{NT,SOLARIS,LINUX}{_optional variant} Here are some possible names from this system: X86_NT (WIN? MSWIN?)X86_NT_MINGNUX86_NT_GNUX86_SOLARISX86_SOLARIS_GNUSPARC_SOLARISSPARC_SOLARIS_GNUPPC_MACX86_MACAMD64_MACPPC64_MACIA64_VMSVAX_VMSALPHA_VMSMIPS_ULTRIXMIPS_IRIXIA64_NTAMD64_NTMIPS_NTPPC_NTPPC_XBOX ?X86_XBOX ?PPC_AIX (Is POWER interesting?)PPC601_AIX ?PPC603_AIX ?G3_MAC ?G4_MAC ?G5_MAC ?PPCG3_MAC ?PPCG4_MAC ? (doesn't run on G3)PPCG4_MAC ? (64 bit, lame names...)X86_MSDOS ?X86_DJGPP ? X86_NT_MWERKS ?X86_NT_DIGITALMARS ?X86_NT_SYMANTEC ?X86_NT_BORLAND ?C_NT ? outputs C code... hm. not right, C gets converted to something else.ALPHA_OSF1  ALPHA_TRU64 ?ALPHA32_NT ?X86_NT_WATCOM ?X86_WINCE ?ARM_WINCE ?ARM_CE ?ARM_MSCE ?ARM_SYMBIAN ?ARM_PALM ?ARM_PALMOS ?X86_BEOS ?68000_OLDMAC ?68020_OLDMAC ? Obviously the vast vast vast vast majority of these don't matter, but as I said it helps to see how a bunch of platforms work out to vet the design. I've held back from...6502_APPLEII, 65816_APPLEIIGS.. 6502_C64 :)65816_SNES ? (Super Nintendo game console) 6502_NES ? (Nintendo...)MIPS_PLAYSTATION ??_SONYPS2 ?PPC_SONYPS3 (Linux runs on this, and maybe previous) SH_DREAMCAST ? (NetBSD runs on this... as does CE)X86_XBOX ? MSBOX ?PPC_XBOX360 (or is it PPC64? Oh, and for these things, you probably need to say MS or LINUX)PPC_MSXBOX360PPC_?XBOX and maybe some virtual machine targets:JVM_ANY ?JAVA_ANY ?MSDOTNET_ANY ?MSIL_ANY ?LLVM_NT ?  Is x86 generically named and people can tweak it. Or call it 686 or I686 and if anyone really has an old processor, they can still tweak and rename and keep the name. Sorry if this is all very annoying. I'm ok with doing nothing here. Ultimately as I said, there isn't even that much code involved, as I recall.It seems to me if you move about 50 lines of cm3 out of cm3 into quake, the matter becomes even less "important", because the config file would be the only thing that cared and would only need to make sense to itself.  - Jay

> Date: Fri, 25 Jan 2008 13:36:49 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > I just wanted to point out why it's call PPC_DARWIN. Now that the> OpenDarwin project has closed down, it may indeed seem strange.> But many of the names can only be understood based on their history.> I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.> > Quoting Jay <jayk123 at hotmail.com>:> > > The PPC_DARWIN port has an optional dependency on X Windows..is that > > available for plain Darwin or only with Mac OS X?> > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.> > > I was surprised by "Darwin", therefore would be.. :)> That's why I tried to explain it ;-)> > > LINUX, LINUXELF, LINUXLIBC6? Please.> > Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > > Linux 1.2 around?> > It could be done now, but it couldn't when it was created.> > > Are the older FreeBSD ABIs so inferior that it is worth having newer > > ones? They didn't have pthreads back then and they do now?> > There are ABI changes with every major release of FreeBSD (and also> Linux, Solaris, and other operating systems if I am not much mistaken).> Of course, everyone strives for compatibility of the often used and> most important interfaces, but there is a grey zone where data> structures common to the kernel and userland are touched, and they> need to be updated (in order to not hinder improvement) more often> than you'd think. If such an update annoys or disturbs users often> enough, new interface abstractions tend to appear that should> avoid the problem for future releases (for example, changes of the> jmp_buf structure break threading code --> new interfaces for thread> context access are defined). The M3 runtime is somewhat special and> differs from the C runtime in that it makes use of quite a number of not> always well-defined system interfaces. We also try to eliminate these> dependencies (VM calls, jmp_buf structure, whole threading, ...)> > Actually I think I was the first one to port any pthread package to> FreeBSD (when working for a company building POS solutions, but we could> never release the code) back in the 1.5 and 2.x days. I used a pthreads> implementation by Frank Mueller.> Official pthread support came much later.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 

Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. 
_________________________________________________________________
Climb to the top of the charts! Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080125/f8515a0a/attachment-0002.html>