2007-06-12 12:36:22 -03:00
|
|
|
@rem Fetches (and builds if necessary) external dependencies
|
|
|
|
|
|
|
|
|
|
@rem Assume we start inside the Python source directory
|
|
|
|
|
cd ..
|
2008-01-09 17:35:04 -04:00
|
|
|
call "%VS90COMNTOOLS%vsvars32.bat"
|
2007-06-12 12:36:22 -03:00
|
|
|
|
|
|
|
|
@rem bzip
|
|
|
|
|
if not exist bzip2-1.0.3 svn export http://svn.python.org/projects/external/bzip2-1.0.3
|
|
|
|
|
|
|
|
|
|
@rem Sleepycat db
|
2008-03-06 09:50:28 -04:00
|
|
|
@rem Remove VS 2003 builds
|
|
|
|
|
if exist db-4.4.20 if not exist db-4.4.20\build_win32\this_is_for_vs9 (
|
|
|
|
|
echo Removing old build
|
|
|
|
|
rd /s/q db-4.4.20
|
|
|
|
|
)
|
|
|
|
|
if not exist db-4.4.20 svn export http://svn.python.org/projects/external/db-4.4.20-vs9 db-4.4.20
|
2007-06-12 12:36:22 -03:00
|
|
|
|
|
|
|
|
@rem OpenSSL
|
2008-01-09 17:35:04 -04:00
|
|
|
if not exist openssl-0.9.8g (
|
|
|
|
|
if exist openssl-0.9.8a rd /s/q openssl-0.9.8a
|
|
|
|
|
svn export http://svn.python.org/projects/external/openssl-0.9.8g
|
|
|
|
|
)
|
2007-06-12 12:36:22 -03:00
|
|
|
|
|
|
|
|
@rem tcltk
|
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 04:45:19 -03:00
|
|
|
if not exist tcl8.4.18.1 (
|
2007-06-12 12:36:22 -03:00
|
|
|
if exist tcltk rd /s/q tcltk
|
2008-01-09 17:35:04 -04:00
|
|
|
if exist tcl8.4.12 rd /s/q tcl8.4.12
|
|
|
|
|
if exist tk8.4.12 rd /s/q tk8.4.12
|
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 04:45:19 -03:00
|
|
|
if exist tcl8.4.16 rd /s/q tcl8.4.16
|
|
|
|
|
if exist tk8.4.16 rd /s/q tk8.4.16
|
|
|
|
|
svn export http://svn.python.org/projects/external/tcl-8.4.18.1
|
|
|
|
|
svn export http://svn.python.org/projects/external/tk-8.4.18.1
|
|
|
|
|
cd tcl-8.4.18.1
|
|
|
|
|
nmake -f makefile.vc COMPILERFLAGS=-DWINVER=0x0500 DEBUG=1 MACHINE=AMD64 INSTALLDIR=../../tcltk64 clean all install
|
|
|
|
|
cd ..\..
|
|
|
|
|
cd tk-8.4.18.1
|
|
|
|
|
nmake -f makefile.vc COMPILERFLAGS=-DWINVER=0x0500 DEBUG=1 MACHINE=AMD64 INSTALLDIR=../../tcltk64 TCLDIR=../../tcl-8.4.18.1 clean all install
|
2007-06-12 12:36:22 -03:00
|
|
|
)
|
2008-01-09 17:35:04 -04:00
|
|
|
|
|
|
|
|
@rem sqlite
|
|
|
|
|
if not exist sqlite-source-3.3.4 svn export http://svn.python.org/projects/external/sqlite-source-3.3.4
|
