<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Native builds are the usual.<br>Cross builds are rarer.<br><br>It is dumb for config files to even specify TARGET.<br> As well as thing I recently added: TARGET_OS, TARGET_ENDIAN.<br><br>It should default to "HOST".<br><br>Furthermore, a command line option rather than<br>editing/replacing config file should achieve<br>a cross build.<br><br>One (or more?) of:<br> cm3 I386_LINUX<br> cm3 -target I386_LINUX<br> cm3 -target:I386_LINUX<br> cm3 -target=I386_LINUX<br> cm3 --target I386_LINUX<br> cm3 --target:I386_LINUX<br> cm3 --target=I386_LINUX<br> cm3 -DTARGET=I386_LINUX<br><br><br>I like the first, but perhaps it is too implicit/sleazy.<br> User should have to say what the random freestanding platform name means? <br> pylib.py does support this.<br>There is much precedent for the last,<br>as cm3 already supports -D. I have found<br>that -D tends to be processed too late to<br>be as useful as it could/should be. We should<br>probably fix this.<br><br><br>Any changes along these lines would "by default"<br>(if not done along with other changes) break other<br>m3quake/m3config users -- m3tohtml, cm3ide, etc.<br><br><br>The code in cm3 that "predefines" stuff, such<br>"HOST", such as defaulting TARGET, shall move<br>into the m3quake package, but not be run "automatically".<br><br><br>m3quake shall remain by default ignorant of its usual use<br>in support of compiling Modula-3 and remain by default<br>"just a scripting language".<br><br><br>Something like<br> m3-sys/m3quake/M3Predefines.i3 <br> m3-sys/m3quake/M3Predefines.Init <br><br><br>Should they start with "Q" or M3"?<br>Should cm3 be split up into cm3lib and cm3exe<br>and these would be m3-sys/cm3lib/M3Predefines?<br><br><br>m3quake users who are attempting to<br>act "like the compiler" shall call M3Predefines.Init().<br><br><br>Furthermore, the following should all be "correctly default"<br>and therefore moved out of config files:<br> INSTALL_ROOT (based on cm3's location) <br> BIN_INSTALL <br> LIB_INSTALL <br> MAN_INSTALL <br> PKG_INSTALL <br> USE_ROOT <br> LIB_USE <br> PKG_USE <br> <br><br>etc. (so much for a precise spec. :) )<br><br>The config file shall still be able to override this. <br>As well as the command line. I think.<br><br><br>There is some order ambiguity.<br>Normally LIB_USE defaults to LIB_INSTALL, etc.<br>If the command line overrides LIB_INSTALL, should<br>that also change LIB_USE?<br><br><br>Perhaps these are not changable on the command line.<br>Does anyone really ever vary them?<br>Sure, people install to custom place, but<br>do they all not follow directly from cm3.exe location?<br><br><br>Well, I sometimes run unshipped cm3.<br>That is something to consider.<br>cm3 should perhaps even move to an archictecture-specific directory.<br> /cm3/bin/I386_LINUX/cm3 <br><br><br>However, aside, I've given up on that idea.<br>While the pkg store has all these nice target-specific directories already,<br>instead of solving the problem for bin and lib, and then having<br>savings due to not duplicating "man", I've just been<br>going with separate entire roots.<br><br>On a Mac for example, I'd have<br> /cm3.x86 <br> /cm3.amd64 <br> /cm3.ppc <br> /cm3.ppc64 (hypothetical) <br><br>or on Windows:<br> /cm3 ("native") <br> /cm3.cygwin <br> /cm3.interix <br><br><br>The "man" directory would be wastefully duplicated.<br><br><br>For the rare user of unshipped cm3 to have to say<br> -DINSTALL_ROOT=/usr/local/bin/cm3<br><br><br>doesn't seem terrible.<br><br><br> - Jay<br></body>
</html>