[M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg

Fri Jan 25 16:07:20 CET 2008

> 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-cygwin
i686-pc-nt
i686-pc-linux
ppc-mac-darwin?
ppc-mac-classic
68k-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 -- mingwin
x86-nt-gcc-gld-xwin-kthr-cyg -- nt386gnu
x86-nt-gcc-gld-xwin-pthr-cyg -- nt386gnu with pthreads
x86-linux-gcc-gld-vga-nothr-newlibx86-linux-icc-glc-nowin-nptl-glibc -- icc Intel compiler
x86-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_MINGNU
X86_NT_GNU
X86_SOLARIS
X86_SOLARIS_GNU
SPARC_SOLARIS
SPARC_SOLARIS_GNU
PPC_MAC
X86_MAC
AMD64_MAC
PPC64_MAC
IA64_VMS
VAX_VMS
ALPHA_VMS
MIPS_ULTRIX
MIPS_IRIX
IA64_NT
AMD64_NT
MIPS_NT
PPC_NT
PPC_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_MSXBOX360
PPC_?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.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080125/9093c0ae/attachment-0002.html>