]>
Commit | Line | Data |
---|---|---|
1 | The collection of scripts in this directory are an attempt to fully | |
2 | automate the build of the wxPython source and binary packages on all | |
3 | build platforms. It does this through creative use of ssh and scp | |
4 | commands to the remote build machines, so this will likely only work | |
5 | in my somewhat unique environment. | |
6 | ||
7 | The goal here is to be able to start a build on one machine and have | |
8 | it take care of all the steps, including moving the source tarball to | |
9 | the other build machines, initiating the build there, and collecting | |
10 | the results. Depending on the type of build, (see below) the results | |
11 | may be copied to a public server for others to play with. | |
12 | ||
13 | Types of builds: | |
14 | ||
15 | dryrun | |
16 | Nothing extra is done with the build, this is just for | |
17 | my own testing. | |
18 | ||
19 | daily | |
20 | The version number is temporarily adjusted to include a | |
21 | datestamp, and if the build is successful the results | |
22 | are copied to a daily build folder on starship. | |
23 | ||
24 | release | |
25 | The results are uploaded to the previews foler on | |
26 | starship if the build is successful. | |
27 | ||
28 | ||
29 | The master script in this folder is build-all (written in Python) | |
30 | which will setup and control the whole process. The other scripts | |
31 | (using bash) are launched from build-all either to do specific tasks | |
32 | locally, or to run on each individual build machine to manage the | |
33 | build process there, usually by calling out to other scripts that | |
34 | already exist. The build-all script uses the taskrunner.py and | |
35 | subprocess Python modules. | |
36 | ||
37 |