[M3devel] host vs. target and host_ostype exposed to quake?

[Jay]

I found Compiler.i3 recently.I had been writing Quake code like:
 
if equal ($OS, "Windows_NT")
 
and:
 
if equal (SL, "/")
 
I propose that the data in Compiler.i3 be exposed to Quake with variable names something like:
HOST -- ALPHA_OSF, NT386, LINUXLIBC6, AMD64_DARWIN, etc.
HOST_OSTYPE -- POSIX, WIN32
/maybe/ booleans thereof:
  HOST_IS_POSIX 
  HOST_IS_WIN32 
 
and /possibly/ others:
HOST_GNU_PLATFORM  -- maybe needed, maybe not -- currently m3makefile maps from HOST, and the config files have unused declarations for the target.
HOST_WORDSIZE -- shouldn't be relevant
 
I /speculate/ as well that the following should be introduced:
TARGET_ARCHITECTURE -- AMD64, I386, PPC (Compiler.i3 already separates this out) 
HOST_ARCHITECTURE
TARGET_OS -- SOLARIS (SOL?), NT, DARWIN (MACOSX? Too late.), LINUX, OSF, VMS, HPUX, FREEBSD, OPENBSD, NETBSD (FBSD, OBSD, NBSD?)
HOST_OS
 
And then, /maybe/ ultimately, the full calculus I have described:
 TARGET_C_LIBRARY -- native, cygwin, ms (multiple versions?)  
 TARGET_C_COMPILER -- gnu, sun, ms, dmars, mwerks, borland, watcom, darwin  
 TARGET_C_LINKER -- similar to previous  
 TARGET_WINDOW_LIBRARY -- xwin, mswin 
 TARGET_THREAD_LIBRARY -- pthreads, alarmthreads, nt 
 
or at least just the very first two:
  HOST -- ALPHA_OSF, NT386, LINUXLIBC6, AMD64_DARWIN, etc.
  HOST_OSTYPE -- POSIX, WIN32
 
This is super easy, like two lines of code in m3quake to expose the data in Compiler.i3.
 
Also, related, all the places that check Pathname.Join(a, b) == a/b or Epoch = 0, should use Compiler.OSType instead, or whatever it is. I'd have to check if Compiler.i3 puts anything in the .i3 vs. the .m3, if in the .m3, that could be slower, but easily fixed too.
 
Oh, and maybe cm3 --print-var HOST.
gcc has all those useful --print flags.
Thus, all the uname stuff in sysinfo could go away, you just default to what the compiler runs on.
You'd override it for cross builds with -D on the command line or a config file as usual (ie: the Quake variable would lose its read-onlyness, possibly taking on a new special form of "write-once").
One downside is that, as written, the config files are more readable and self-documenting by starting with the important settings up front. Whatever is buried in cm3 is more hidden from users, good and bad.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080422/208f4b9b/attachment-0002.html>