wxWidgets

History

Robin Dunn cbfc9df676 Merge recent changes from 2.8 branch. Make updates for recent changes on CVS HEAD. Remove or workaround deprecated items. Fix compile errors. git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@45088 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775		2007-03-27 01:49:46 +00:00
..
build-all	Merge recent changes from 2.8 branch.	2007-03-27 01:49:46 +00:00
build-deb	Merge recent changes from 2.8 branch.	2007-03-27 01:49:46 +00:00
build-docs
build-environ.cfg	get rid of one of the extra slashes in the download URLs	2006-12-08 02:46:22 +00:00
build-finalize
build-osx
build-rpm
build-setup
build-sources
build-windows	Build and distrib tweaks	2007-01-21 07:03:55 +00:00
daily
do-build-deb
do-build-osx
do-build-rpm
do-build-windows	Build and distrib tweaks	2007-01-21 07:03:55 +00:00
dryrun
README.txt
release
subprocess.py
taskrunner.py	Build and distrib tweaks	2007-01-21 07:03:55 +00:00
tr_setup.py

README.txt

The collection of scripts in this directory are an attempt to fully
automate the build of the wxPython source and binary packages on all
build platforms.  It does this through creative use of ssh and scp
commands to the remote build machines, so this will likely only work
in my somewhat unique environment.

The goal here is to be able to start a build on one machine and have
it take care of all the steps, including moving the source tarball to
the other build machines, initiating the build there, and collecting
the results.  Depending on the type of build, (see below) the results
may be copied to a public server for others to play with.

Types of builds:

      dryrun
		Nothing extra is done with the build, this is just for
		my own testing.  

      daily 
		The version number is temporarily adjusted to include a
		datestamp, and if the build is successful the results
		are copied to a daily build folder on starship.

      release
		The results are uploaded to the previews foler on
		starship if the build is successful.


The master script in this folder is build-all (written in Python)
which will setup and control the whole process.  The other scripts
(using bash) are launched from build-all either to do specific tasks
locally, or to run on each individual build machine to manage the
build process there, usually by calling out to other scripts that
already exist.  The build-all script uses the taskrunner.py and
subprocess Python modules.