[pony-build] extended command-line options for build scripts

[Jack Carlson]

Recent additions to my pony-build branch:

- The python executable used for building can be changed via command line with the -e option.  Note that adding the new python executable name to the arguments list without the -e option will no longer work--it will cause the build script to error out instead.  Also, the version of python used no longer needs to be set in the build script--a default value is set in pony-client.  This of course can be easily overridden, but should cut down on redundant information.
[ http://github.com/JackCarlson/pony-build/commit/5cbfe68cc5778d4c69f92cd50b139ddf07e4bb2b ]

- Tags can now by set via command-line with the -t option.  Enter tags as a comma-delimited list (not space-delimited, for obvious reasons).
[ http://github.com/JackCarlson/pony-build/commit/13367b31d87204a4b85ab7312d7deab4ecad4c89 ]

- The build scripts should be able to verify if the given version of python actually exists on the system.  If it does not, a warning will be displayed and the build script will exit.

I don't have a link for this latest push, as github doesn't seem to be reflecting the change yet--but my machine is insisting that everything is "up-to-date".

---------------------------

What next:

One thing I'd like to tackle next (if there aren't any more pressing issues) is the structuring of the build scripts and of pony-client.py itself.  I feel there is a lot of redundant code/variables in these build scripts, and think almost all the code in the build scripts could be moved into a pony-client class.  Variables such as the default pony-build server to be used, default python executable, etc could be stored in a config file.  With these changes, it'd be possible to get the build scripts down to just a couple lines of code each, but still be just as configurable as they are now.

One argument against this that I can think of is what if the build environment changes much--for example, the default version of Python changes to a newer version, then the users would have to go back and update every build script if they were relying the default before (if that makes sense?).  Not sure if this would be a big issue though, as any dedicated build system that would have enough build scripts to make this an issue should probably be a stable environment anyway.  Also, if this were a foreseeable outcome, the build scripts should probably have been written to override the default python version from this config file in the first place.

Any other thoughts/ideas about this?

---------------------------

One other question (aimed at Titus, but if anyone else knows, let me know!): what is a "stale build", and what is the "request build" link actually supposed to do?

-Jack