[M3devel] determing current processor as string

[Jay]

Thoughts here?
 
Does the processor need to be "friendly" and "precise" including stuff
not knowable at compile time (386 vs. 486 vs. 586, etc.),
or would just "PowerPC" or "PPC" suffice?
 
 
This question affects the Posix code.
 
 
The Posix code tries to fetch some data at runtime from uname, and if that fails
it falls back to built in data. Besides that the data is used in an unlikely
error path, we bother carrying the data for all systems, which afaik
is completely unnecessary. Once I confirm, I'll have Quake generate
just what is needed.
 
 
Similarly, I think cm3 should have -print-host or somesuch.
Then the platform probing in sysinfo.sh could probably all go away.
(Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/cm3.)
 
 
There is more here than just the processor.
So some runtime code would remain, even if the processor
became hard coded at compile time.
 
You know, there are a few models here:
   
  Use data at runtime asis.
    e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done.
    Does that work on CE?
 
  Build-in the data at compile time and be done.
     This requires possibly a revisit for every port, but simple.
      It goes obsolete in time, but not quietly, it'd be an error in the Quake code
          when a new platform is introduced.
     Or, if the string is just <TARGET> then automatically ports, no revisit.
     This doesn't have the concern "does it work on CE?" or
       of Posix vs. Win32 portability. 
 
  Use data at runtime to pick among compile time data.
     This is the current approach and it goes obsolete quietly in time.
 
 
As well, these functions are never even used that I can see.
Remove them?
Or assume they might be used outside the cm3 tree?
 
(That's quite a "line" in decision makiing. It's so much nicer
to assume/know you have all the relevant code visible and therefore
can make any change, provided you fix the client code, vs. having to
assume there is "anything" out there.)
 
 - Jay> Date: Fri, 2 Jan 2009 21:22:55 +0000> To: m3commit@> From: jkrell@> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 09/01/02 21:22:55> > Modified files:> cm3/m3-libs/libm3/src/os/WIN32/: OSConfigWin32.m3 > > Log message:> add in some missing architectures, though arguably this should be either GetEnv(PROCESSOR_ARCHITECTURE) (does it work on CE?) or a constant determined at build time; the historical code goes obsolete automatically and quietly> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090104/3bda5e05/attachment-0001.html>