[M3devel] wierdness around user overrides vs. uname in sysinfo.sh?
wagner at elegosoft.com
Fri Dec 28 17:35:40 CET 2007
Quoting Jay <jayk123 at hotmail.com>:
> [another tactic attempted...]
>> From: jayk123 at hotmail.com
>> To: jayk123 at hotmail.com
>> Subject: test
>> Date: Fri, 28 Dec 2007 11:15:58 +0000
>> I wanted to change upgrade.sh to have the following features:
>> 1) optionally skip building m3cc, since it is the slowest part
will do just that for all shell scripts, IIRC.
>> 2) optionally clean between various steps, as was apparently
>> necessary for me
It should not be difficult to add that. Something like
. "$ROOT/scripts/do-cm3-core.sh" realclean || exit 1
should do the trick.
>> I really cannot hack sh though. Sorry. I've tried several times
>> through the years.
>> I just can't stand these languages where pretty much everything is a string.
>> e.g. sh, Tcl, cmd.
>> I admit hypocrisy in that I can and have hacked cmd.
>> So I started rewriting scripts/* in Python.
>> I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my
>> access revoked), just add a new scripts/python directory.
>> Tempting to call it scripts/jay.
>> I'm making good progess here.
No harm in that. You may either put the python scripts beside the shell
scripts and simply call them *.py, or put them in a subdirectory
python or py. Don't call it Jay.
>> Actually I started with Perl, which I have more experience with, but
>> it was frustrating and...
>> Anyway, so the real point here is, I'm reading scripts/* fairly closely.
>> I'd like to at times bounce my interpretation off folks.
>> In particular, I detect some massive wierdness.
>> Most variables can be set by the caller.
>> I assume that is mostly meant for the user to override things.
>> I agree that is mostly a good thing.
>> However it seems often data is derived, and then later overrides
>> can kick in.
These are just some simple and useful scripts for maintenance; there
was never an overall system design.
>> In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname.
>> And it sets CM3_TARGET.
>> But TARGET is then set via the user override, or CM3_TARGET if no
>> user override.
>> I draw one of two conclusions:
>> If a user sets TARGET, such as for a cross build, then user darn well better
>> set other variables manually to.
>> OR sysinfo.sh ought to check for TARGET being set, and derive data
>> from that.
>> It should check preset TARGET or uname, not both.
>> I'm just going to leave it alone.
If you find obvious inconsistencies or mistakes, don't hesitate to
suggest a correction.
>> Presumably mostly the overrides are never set.
>> They are mainly for cross builds and/or bringing up new targets probably.
Cross building is the usual way of porting the compiler to a new
target, so it's done more often than you might assume. I've done it
lots of times.
>> There aren't THAT MANY variables anyway.
>> Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc.
>> Some are only for Win32.
>> Maybe after this I'll try rewriting scripts in Quake. :)
That would be interesting, too. But don't forget that all these
scripts are just more or less simple tools for installation and
maintenance; the important asset is in all the M3 code.
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
More information about the M3devel