[M3devel] proposal for next release: moving some config file content into cm3

[Jay K]

Native builds are the usual.
Cross builds are rarer.

It is dumb for config files to even specify TARGET.
  As well as thing I recently added: TARGET_OS, TARGET_ENDIAN.

It should default to "HOST".

Furthermore, a command line option rather than
editing/replacing config file should achieve
a cross build.

One (or more?) of:
  cm3 I386_LINUX
  cm3 -target I386_LINUX
  cm3 -target:I386_LINUX
  cm3 -target=I386_LINUX
  cm3 --target I386_LINUX
  cm3 --target:I386_LINUX
  cm3 --target=I386_LINUX
  cm3 -DTARGET=I386_LINUX


I like the first, but perhaps it is too implicit/sleazy.
  User should have to say what the random freestanding platform name means? 
  pylib.py does support this.
There is much precedent for the last,
as cm3 already supports -D. I have found
that -D tends to be processed too late to
be as useful as it could/should be. We should
probably fix this.


Any changes along these lines would "by default"
(if not done along with other changes) break other
m3quake/m3config users -- m3tohtml, cm3ide, etc.


The code in cm3 that "predefines" stuff, such
"HOST", such as defaulting TARGET, shall move
into the m3quake package, but not be run "automatically".


m3quake shall remain by default ignorant of its usual use
in support of compiling Modula-3 and remain by default
"just a scripting language".


Something like
  m3-sys/m3quake/M3Predefines.i3  
  m3-sys/m3quake/M3Predefines.Init  


Should they start with "Q" or M3"?
Should cm3 be split up into cm3lib and cm3exe
and these would be m3-sys/cm3lib/M3Predefines?


m3quake users who are attempting to
act "like the compiler" shall call M3Predefines.Init().


Furthermore, the following should all be "correctly default"
and therefore moved out of config files:
  INSTALL_ROOT (based on cm3's location) 
  BIN_INSTALL 
  LIB_INSTALL 
  MAN_INSTALL 
  PKG_INSTALL  
  USE_ROOT  
  LIB_USE  
  PKG_USE 
  

etc. (so much for a precise spec. :) )

The config file shall still be able to override this. 
As well as the command line.  I think.


There is some order ambiguity.
Normally LIB_USE defaults to LIB_INSTALL, etc.
If the command line overrides LIB_INSTALL, should
that also change LIB_USE?


Perhaps these are not changable on the command line.
Does anyone really ever vary them?
Sure, people install to  custom place, but
do they all not follow directly from cm3.exe location?


Well, I sometimes run unshipped cm3.
That is something to consider.
cm3 should perhaps even move to an archictecture-specific directory.
   /cm3/bin/I386_LINUX/cm3 


However, aside, I've given up on that idea.
While the pkg store has all these nice target-specific directories already,
instead of solving the problem for bin and lib, and then having
savings due to not duplicating "man", I've just been
going with separate entire roots.

On a Mac for example, I'd have
  /cm3.x86  
  /cm3.amd64  
  /cm3.ppc  
  /cm3.ppc64 (hypothetical)  

or on Windows:
  /cm3 ("native")  
  /cm3.cygwin  
  /cm3.interix  


The "man" directory would be wastefully duplicated.


For the rare user of unshipped cm3 to have to say
  -DINSTALL_ROOT=/usr/local/bin/cm3


doesn't seem terrible.


 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090810/91cf87c4/attachment-0001.html>