a38379649b
Explicitly refer to current hhp file (2.6a3)
2008-05-10 13:24:09 +00:00
5a4d66824a
Don't run kill_python as part of the build process. Change the buildbots so they have to call it explicitly instead.
2008-04-06 20:51:23 +00:00
d6dffbcc28
Reimplement kill_python. The existing version had a number of flaws, namely, it didn't work for x64 and it wasn't precise about which python_d.exe it was killing -- it just killed the first one it came across that happened to have 'pcbuild\python_d.exe' or 'build\python_d.exe' in it's path. The new version has been rewritten from the ground up and now lives in PCbuild, instead of Tools\buildbot, and it has also been incorporated into the Visual Studio solution (pcbuild.sln) as 'kill_python'. The solution has also been altered such that kill_python is called where necessary in the build process in order to prevent any linking errors due to open file locks. In lieu of this, all of the existing bits and pieces in Tools\buildbot that called out to kill_python at various points have also been removed as they are now obsolete. Tested on both Win32 and x64.
...
Change set (included to improve usefulness of svnmerge log entry):
M PCbuild\pythoncore.vcproj
M PCbuild\pcbuild.sln
M PCbuild\release.vsprops
A PCbuild\kill_python.vcproj
M PCbuild\debug.vsprops
A PCbuild\kill_python.c
D Tools\buildbot\kill_python.bat
D Tools\buildbot\kill_python.mak
M Tools\buildbot\build.bat
D Tools\buildbot\Makefile
M Tools\buildbot\build-amd64.bat
M Tools\buildbot\buildmsi.bat
D Tools\buildbot\kill_python.c
2008-04-03 18:27:06 +00:00
980c598936
Remove the building of Berkeley DB step; _bsddb44.vcproj takes care of this for us now.
2008-04-03 15:39:17 +00:00
27f60a65e8
Comment out tcltk/tcltk64 removal.
2008-03-19 22:41:10 +00:00
e7abf20ce7
Force a clean of the tcltk/tcltk64 directories now that we've completely changed the tcl/tk build environment.
2008-03-19 21:51:16 +00:00
611c86b7d1
Fix the x64 Windows build environment used by the buildbots. %VS90COMNTOOLS%\vsvars32.bat is fine for 32-bit builds, but doesn't work for x64 builds, regardless of /MACHINE:AMD64 and /USECL:MS_OPTERON flags passed to cl.exe. Launch the x86_64 cross compilation environment via '%VS90COMNTOOLS%\..\..\VC\vcvarsall.bat x86_amd64'. I don't have access to any systems *without* Visual Studio 2008 Professional installed (i.e. just Express Edition), so I can't test if x64 compilation works w/ VS Express at the moment.
...
Additionally, force a clean in our build.bat files before building, just whilst we're going through these build system updates.
And finally, add in the missing MACHINE=AMD64 option to our Tcl/Tk x64 build.
2008-03-19 21:11:55 +00:00
12b580b2c6
Checkout sqlite-source when it is not there.
2008-03-19 16:10:57 +00:00
4f4738f015
Lets have another try at getting the Windows buildbots in a consistent state before rebuilding using the new process.
2008-03-19 09:23:08 +00:00
4fbaacaa12
Fix the tcl-8.4.18.1 path and make sure we cd into the right directory when building tcl/tk.
2008-03-19 08:06:03 +00:00
05a96641b4
Refine the Visual Studio 2008 build solution in order to improve how we deal with external components, as well as fixing outstanding issues with Windows x64 build support. Introduce two new .vcproj files, _bsddb44.vcproj and sqlite3.vcproj, which replace the previous pre-link event scripts for _bsddb and _sqlite3 respectively. The new project files inherit from our property files as if they were any other Python module. This has numerous benefits. First, the components get built with exactly the same compiler flags and settings as the rest of Python. Second, it makes it much easier to debug problems in the external components when they're part of the build system. Third, they'll benefit from profile guided optimisation in the release builds, just like the rest of Python core.
...
I've also introduced a slightly new pattern for managing externals in subversion. New components get checked in as <name>-<version>.x, where <version> matches the exact vendor version string. After the initial import of the external component, the .x is tagged as .0 (i.e. tcl-8.4.18.x -> tcl-8.4.18.0). Some components may not need any tweaking, whereas there are others that might (tcl/tk fall into this bucket). In that case, the relevant modifications are made to the .x branch, which will be subsequently tagged as .1 (and then n+1 going forward) when they build successfully and all tests pass. Buildbots will be converted to rely on these explicit tags only, which makes it easy for us to switch them over to a new version as and when required. (Simple change to external(-amd64).bat: if we've bumped tcl to 8.4.18.1, change the .bat to rmdir 8.4.18.0 if it exists and check out a new .1 copy.)
2008-03-19 07:45:19 +00:00
f2b333a0c9
Run debug version, cd to PCbuild.
2008-03-14 21:19:28 +00:00
7bae4432a3
Use -x64 flag.
2008-03-14 13:57:59 +00:00
db311ba588
Update db-4.4.20 build procedure.
2008-03-06 13:50:28 +00:00
4291b19d4e
cd PCbuild only after deleting all pyc files.
2008-03-05 22:24:31 +00:00
8b6552deb3
Build db-4.4.20 with VS9; remove VS2003 build if necessary.
2008-02-29 18:17:23 +00:00
61390fd884
Change amd64 buildbot scripts to use Visual Studio 2008, and
...
to use the required versions of external sources.
External sources are not yet built, so the build-step fails to
built some targets.
2008-01-09 21:35:43 +00:00
f71b59b072
Change amd64 buildbot scripts to use Visual Studio 2008, and
...
to use the required versions of external sources.
External sources are not yet built, so the build-step fails to
built some targets.
2008-01-09 21:35:04 +00:00
4b3311b25b
Use vcbuild for VS 2009.
2008-01-06 10:09:48 +00:00
9fd2bcf654
Test in PCbuild directory.
2008-01-01 23:36:24 +00:00
76f1c1f304
Use Visual Studio 2009 on the build slaves.
2008-01-01 23:00:48 +00:00
656dc2adee
Fix paths for build bot
2007-12-31 14:59:26 +00:00
f0a5b09db2
Clean both Release and Debug projects, to support
...
the MSI builder.
2007-09-14 06:49:43 +00:00
0dda1e9e94
More path fixes.
2007-09-13 13:27:27 +00:00
4bd037df5d
Fix path.
2007-09-13 10:38:42 +00:00
82151c67a4
Add more automated actions.
2007-09-13 09:59:00 +00:00
342cff6d55
Require that bash.exe is on the path, along with the rest of Cygwin.
2007-09-10 13:30:38 +00:00
42cdada8ce
Update before making htmlhelp.
2007-09-10 13:20:03 +00:00
fbf83bbd77
Beginnings of a "build MSI" step.
2007-09-10 10:22:05 +00:00
22000cbd6b
Build bzip2.
2007-06-13 07:54:57 +00:00
635d7a224a
Notes about building tcl/tk for windows/AMD64.
2007-06-13 07:07:41 +00:00
92094d0f1c
Do not hardcode the buildbot's directory name.
2007-06-13 07:07:03 +00:00
de15cdf995
Don't rebuild Berkeley DB if not needed (this was committed by accident).
2007-06-12 19:56:12 +00:00
285216ca30
Add bufferoverflowU.lib to PCBuild\_bsddb.vcproj.
...
Build sqlite3.dll and bsddb.
2007-06-12 19:02:59 +00:00
04d17b4660
Checkout, but do not yet try to build, exernal sources.
2007-06-12 15:36:22 +00:00
80958081df
Need to set the environment variables, otherwise devenv.com is not found.
2007-06-10 18:27:54 +00:00
3608a163a6
First version of build scripts for Windows/AMD64 (no external
...
components are built yet, and 'kill_python' is disabled).
2007-06-10 15:59:17 +00:00
59e9ac8ebe
Merge 51340 and 51341 from 2.5 branch:
...
Leave tk build directory to restore original path.
Invoke debug mk1mf.pl after running Configure.
2006-08-17 19:19:32 +00:00
e4abc232d5
Don't kill a normal instance of python running on windows when checking
...
to kill a cygwin instance. build\\python.exe was matching a normal windows
instance. Prefix that with a \\ to ensure build is a directory and not
PCbuild. As discussed on python-dev.
2006-07-27 03:51:58 +00:00
787fe6d9f6
Port cygwin kill_python changes from 2.4 branch.
2006-06-10 08:14:03 +00:00
70f5f7a9f4
Use GetModuleFileNameEx instead of GetProcessImageFileName,
...
as the latter is not available on Windows 2000.
2006-04-17 17:26:42 +00:00
ce8607df96
Revert to 45478, disable kill_python command for now.
2006-04-17 10:39:39 +00:00
c97c11958d
Check whether disk space is full.
2006-04-17 10:36:18 +00:00
63d1f99d7a
Rename binary again; increase noise; stop trying to actually kill the process.
2006-04-17 10:31:35 +00:00
11e8b3c29b
Rename binaries again; increase noise.
2006-04-17 10:27:28 +00:00
98dbfab909
Rename binary to avoid conflicts with hanging processes on x86 w2k.
2006-04-17 10:23:23 +00:00
5b3bf0dd5e
Try some tracing
2006-04-17 10:19:25 +00:00
2d12372e32
Add kill_python command.
2006-04-17 09:46:47 +00:00
ed2038b599
The part checking for the sqlite DLL was looking at, and
...
copying to, a wrong location (it copied the DLL under the
Python directory, and gave it name 'PCbuild').
The Windows buildbots other than mine are probably hung
now, waiting for someone to press "OK" on a popup box
informing them that sqlite3.dll couldn't be found.
2006-04-04 19:12:51 +00:00
b2fc21e9f8
sqlite on Windows:
...
- The buildbot "fetch it" step failed at the end, due to
using Unix syntax in the final "copy the DLL" step.
test_sqlite was skipped as a result.
- test_sqlite is no longer an expected skip on Windows.
2006-04-04 15:21:02 +00:00
Martin v. Löwis
Trent Nelson
Thomas Heller
Christian Heimes
Neal Norwitz
Tim Peters