traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
cpython/PCbuild/pyproject.vsprops

112 lines
2.3 KiB
Plaintext
Raw Normal View History

Backport of the PCbuild9 directory from the py3k branch. I've finished the last task for the PCbuild9 directory today. I don't think there is much left to do. Now you can all play around with the shiny new VS 2008 and try the PGO builds. I was able to get a speed improvement of about 10% on py3k. Have fun! :)
2007-11-22 07:21:16 -04:00
<?xml version="1.0" encoding="Windows-1252"?>
<VisualStudioPropertySheet
ProjectType="Visual C++"
Version="8.00"
Name="pyproject"
OutputDirectory="$(SolutionDir)"
IntermediateDirectory="$(SolutionDir)$(PlatformName)-temp-$(ConfigurationName)\$(ProjectName)\"
>
<Tool
Name="VCCLCompilerTool"
Optimization="2"
InlineFunctionExpansion="1"
EnableIntrinsicFunctions="true"
AdditionalIncludeDirectories="..\Include; ..\PC"
Several Windows related cleanups: * Removed a #define from pyconfig.h. The macro was already defined a few lines higher. * Fixed path to tix in the build_tkinter.py script * Changed make_buildinfo.c to use versions of unlink and strcat which are considered safe by Windows (as suggested by MvL). * Removed two defines from pyproject.vsprops that are no longer required. Both are defined in pyconfig.h and make_buildinfo.c doesn't use the unsafe versions any more (as suggested by MvL). * Added some more information about PGO and the property files to PCbuild9/readme.txt. Are you fine with the changes, Martin?
2007-12-06 17:13:06 -04:00
PreprocessorDefinitions="_WIN32"
Backport of the PCbuild9 directory from the py3k branch. I've finished the last task for the PCbuild9 directory today. I don't think there is much left to do. Now you can all play around with the shiny new VS 2008 and try the PGO builds. I was able to get a speed improvement of about 10% on py3k. Have fun! :)
2007-11-22 07:21:16 -04:00
StringPooling="true"
ExceptionHandling="0"
RuntimeLibrary="0"
EnableFunctionLevelLinking="true"
WarningLevel="3"
DebugInformationFormat="3"
CompileAs="0"
/>
<Tool
Name="VCLinkerTool"
LinkIncremental="1"
AdditionalLibraryDirectories="$(OutDir)"
GenerateDebugInformation="true"
ProgramDatabaseFile="$(OutDir)$(TargetName).pdb"
SubSystem="2"
RandomizedBaseAddress="1"
DataExecutionPrevention="0"
TargetMachine="1"
/>
<Tool
Name="VCResourceCompilerTool"
AdditionalIncludeDirectories="..\PC;..\Include"
/>
<UserMacro
Name="PyDllName"
Update version number to 2.7.
2008-10-03 07:59:55 -03:00
Value="python27"
Backport of the PCbuild9 directory from the py3k branch. I've finished the last task for the PCbuild9 directory today. I don't think there is much left to do. Now you can all play around with the shiny new VS 2008 and try the PGO builds. I was able to get a speed improvement of about 10% on py3k. Have fun! :)
2007-11-22 07:21:16 -04:00
/>
Backport of changes to PCbuild9 from the py3k branch
2007-11-27 17:28:40 -04:00
<UserMacro
Name="PythonExe"
Value="$(SolutionDir)\python.exe"
/>
Introduce a user macro named $(externalsDir), which should point to the root directory of where all the external sources should live. Developers can change this value if their external sources live elsewhere. The default of '..\..' matches the current status quo.
2008-05-23 17:33:14 -03:00
<UserMacro
Name="externalsDir"
Value="..\.."
/>
Backport of the PCbuild9 directory from the py3k branch. I've finished the last task for the PCbuild9 directory today. I don't think there is much left to do. Now you can all play around with the shiny new VS 2008 and try the PGO builds. I was able to get a speed improvement of about 10% on py3k. Have fun! :)
2007-11-22 07:21:16 -04:00
<UserMacro
Name="bsddbDir"
Merged revisions 64368-64369 via svnmerge from svn+ssh://pythondev@svn.python.org/python/branches/tnelson-trunk-bsddb-47-upgrade ........ r64368 | trent.nelson | 2008-06-17 23:13:44 -0500 (Tue, 17 Jun 2008) | 1 line Initial commit of work pertaining to switching the Windows build from Berkeley DB 4.4.20 to 4.7.25. Note that I've deprecated the standalone '_bsddb44.vcproj' in lieu of adding the sources in a separate folder to the _bsddb project. This was a conscious decision and actually makes everything far more easier to manage. With this approach, entire test suite passed straight off the bat. Well, almost -- the timeout in bsddb/test/test_replication.py needed bumping up a little -- 2 seconds was too short. 10 seconds seems to be fine for me, but I'll make sure Jesus verifies. More documentation to come once I've been able to test out this approach on the buildbots (hence keeping the changes in a separate branch for now). ........ r64369 | trent.nelson | 2008-06-17 23:19:12 -0500 (Tue, 17 Jun 2008) | 1 line Bump Berkeley DB version from 4.4.20 to 4.7.25. ........
2008-06-26 23:30:34 -03:00
Value="$(bsddb47Dir)"
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
/>
<UserMacro
Name="bsddbDepLibs"
Merged revisions 64368-64369 via svnmerge from svn+ssh://pythondev@svn.python.org/python/branches/tnelson-trunk-bsddb-47-upgrade ........ r64368 | trent.nelson | 2008-06-17 23:13:44 -0500 (Tue, 17 Jun 2008) | 1 line Initial commit of work pertaining to switching the Windows build from Berkeley DB 4.4.20 to 4.7.25. Note that I've deprecated the standalone '_bsddb44.vcproj' in lieu of adding the sources in a separate folder to the _bsddb project. This was a conscious decision and actually makes everything far more easier to manage. With this approach, entire test suite passed straight off the bat. Well, almost -- the timeout in bsddb/test/test_replication.py needed bumping up a little -- 2 seconds was too short. 10 seconds seems to be fine for me, but I'll make sure Jesus verifies. More documentation to come once I've been able to test out this approach on the buildbots (hence keeping the changes in a separate branch for now). ........ r64369 | trent.nelson | 2008-06-17 23:19:12 -0500 (Tue, 17 Jun 2008) | 1 line Bump Berkeley DB version from 4.4.20 to 4.7.25. ........
2008-06-26 23:30:34 -03:00
Value="$(bsddb47DepLibs)"
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
/>
<UserMacro
Name="bsddb44Dir"
Introduce a user macro named $(externalsDir), which should point to the root directory of where all the external sources should live. Developers can change this value if their external sources live elsewhere. The default of '..\..' matches the current status quo.
2008-05-23 17:33:14 -03:00
Value="$(externalsDir)\db-4.4.20\build_win32"
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
/>
<UserMacro
Name="bsddb44DepLibs"
Value=""
/>
<UserMacro
Merged revisions 64368-64369 via svnmerge from svn+ssh://pythondev@svn.python.org/python/branches/tnelson-trunk-bsddb-47-upgrade ........ r64368 | trent.nelson | 2008-06-17 23:13:44 -0500 (Tue, 17 Jun 2008) | 1 line Initial commit of work pertaining to switching the Windows build from Berkeley DB 4.4.20 to 4.7.25. Note that I've deprecated the standalone '_bsddb44.vcproj' in lieu of adding the sources in a separate folder to the _bsddb project. This was a conscious decision and actually makes everything far more easier to manage. With this approach, entire test suite passed straight off the bat. Well, almost -- the timeout in bsddb/test/test_replication.py needed bumping up a little -- 2 seconds was too short. 10 seconds seems to be fine for me, but I'll make sure Jesus verifies. More documentation to come once I've been able to test out this approach on the buildbots (hence keeping the changes in a separate branch for now). ........ r64369 | trent.nelson | 2008-06-17 23:19:12 -0500 (Tue, 17 Jun 2008) | 1 line Bump Berkeley DB version from 4.4.20 to 4.7.25. ........
2008-06-26 23:30:34 -03:00
Name="bsddb47Dir"
Value="$(externalsDir)\db-4.7.25.0\build_windows"
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
/>
<UserMacro
Merged revisions 64368-64369 via svnmerge from svn+ssh://pythondev@svn.python.org/python/branches/tnelson-trunk-bsddb-47-upgrade ........ r64368 | trent.nelson | 2008-06-17 23:13:44 -0500 (Tue, 17 Jun 2008) | 1 line Initial commit of work pertaining to switching the Windows build from Berkeley DB 4.4.20 to 4.7.25. Note that I've deprecated the standalone '_bsddb44.vcproj' in lieu of adding the sources in a separate folder to the _bsddb project. This was a conscious decision and actually makes everything far more easier to manage. With this approach, entire test suite passed straight off the bat. Well, almost -- the timeout in bsddb/test/test_replication.py needed bumping up a little -- 2 seconds was too short. 10 seconds seems to be fine for me, but I'll make sure Jesus verifies. More documentation to come once I've been able to test out this approach on the buildbots (hence keeping the changes in a separate branch for now). ........ r64369 | trent.nelson | 2008-06-17 23:19:12 -0500 (Tue, 17 Jun 2008) | 1 line Bump Berkeley DB version from 4.4.20 to 4.7.25. ........
2008-06-26 23:30:34 -03:00
Name="bsddb47DepLibs"
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
Value="ws2_32.lib"
Backport of the PCbuild9 directory from the py3k branch. I've finished the last task for the PCbuild9 directory today. I don't think there is much left to do. Now you can all play around with the shiny new VS 2008 and try the PGO builds. I was able to get a speed improvement of about 10% on py3k. Have fun! :)
2007-11-22 07:21:16 -04:00
/>
<UserMacro
Name="sqlite3Dir"
Switch to SQLite 3.5.9.
2008-06-13 15:12:51 -03:00
Value="$(externalsDir)\sqlite-3.5.9"
Backport of the PCbuild9 directory from the py3k branch. I've finished the last task for the PCbuild9 directory today. I don't think there is much left to do. Now you can all play around with the shiny new VS 2008 and try the PGO builds. I was able to get a speed improvement of about 10% on py3k. Have fun! :)
2007-11-22 07:21:16 -04:00
/>
<UserMacro
Name="bz2Dir"
Switch to bzip2 1.0.5.
2008-06-13 14:22:39 -03:00
Value="$(externalsDir)\bzip2-1.0.5"
Backport of the PCbuild9 directory from the py3k branch. I've finished the last task for the PCbuild9 directory today. I don't think there is much left to do. Now you can all play around with the shiny new VS 2008 and try the PGO builds. I was able to get a speed improvement of about 10% on py3k. Have fun! :)
2007-11-22 07:21:16 -04:00
/>
<UserMacro
Name="opensslDir"
Switch to OpenSSL 0.9.8l.
2009-12-21 15:27:15 -04:00
Value="$(externalsDir)\openssl-0.9.8l"
Backport of the PCbuild9 directory from the py3k branch. I've finished the last task for the PCbuild9 directory today. I don't think there is much left to do. Now you can all play around with the shiny new VS 2008 and try the PGO builds. I was able to get a speed improvement of about 10% on py3k. Have fun! :)
2007-11-22 07:21:16 -04:00
/>
<UserMacro
Name="tcltkDir"
Introduce a user macro named $(externalsDir), which should point to the root directory of where all the external sources should live. Developers can change this value if their external sources live elsewhere. The default of '..\..' matches the current status quo.
2008-05-23 17:33:14 -03:00
Value="$(externalsDir)\tcltk"
Backport of the PCbuild9 directory from the py3k branch. I've finished the last task for the PCbuild9 directory today. I don't think there is much left to do. Now you can all play around with the shiny new VS 2008 and try the PGO builds. I was able to get a speed improvement of about 10% on py3k. Have fun! :)
2007-11-22 07:21:16 -04:00
/>
Backport of changes to PCbuild9 from the py3k branch
2007-11-27 17:28:40 -04:00
<UserMacro
Name="tcltk64Dir"
Introduce a user macro named $(externalsDir), which should point to the root directory of where all the external sources should live. Developers can change this value if their external sources live elsewhere. The default of '..\..' matches the current status quo.
2008-05-23 17:33:14 -03:00
Value="$(externalsDir)\tcltk64"
Backport of changes to PCbuild9 from the py3k branch
2007-11-27 17:28:40 -04:00
/>
Fixed for #1601: IDLE not working correctly on Windows (Py30a2/IDLE30a1) Amaury's ideas works great. Should we build the Python core with WINVER=0x0500 and _WIN32_WINNT=0x0500, too?
2007-12-17 23:38:03 -04:00
<UserMacro
Name="tcltkLib"
Switch to Tcl/Tk 8.5.
2008-06-12 15:52:00 -03:00
Value="$(tcltkDir)\lib\tcl85.lib $(tcltkDir)\lib\tk85.lib"
Fixed for #1601: IDLE not working correctly on Windows (Py30a2/IDLE30a1) Amaury's ideas works great. Should we build the Python core with WINVER=0x0500 and _WIN32_WINNT=0x0500, too?
2007-12-17 23:38:03 -04:00
/>
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
<UserMacro
Name="tcltkLibDebug"
Switch to Tcl/Tk 8.5.
2008-06-12 15:52:00 -03:00
Value="$(tcltkDir)\lib\tcl85g.lib $(tcltkDir)\lib\tk85g.lib"
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
/>
Fixed for #1601: IDLE not working correctly on Windows (Py30a2/IDLE30a1) Amaury's ideas works great. Should we build the Python core with WINVER=0x0500 and _WIN32_WINNT=0x0500, too?
2007-12-17 23:38:03 -04:00
<UserMacro
Name="tcltk64Lib"
Switch to Tcl/Tk 8.5.
2008-06-12 15:52:00 -03:00
Value="$(tcltk64Dir)\lib\tcl85.lib $(tcltk64Dir)\lib\tk85.lib"
Fixed for #1601: IDLE not working correctly on Windows (Py30a2/IDLE30a1) Amaury's ideas works great. Should we build the Python core with WINVER=0x0500 and _WIN32_WINNT=0x0500, too?
2007-12-17 23:38:03 -04:00
/>
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
<UserMacro
Name="tcltk64LibDebug"
Switch to Tcl/Tk 8.5.
2008-06-12 15:52:00 -03:00
Value="$(tcltk64Dir)\lib\tcl85g.lib $(tcltk64Dir)\lib\tk85g.lib"
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
/>
Backport of the PCbuild9 directory from the py3k branch. I've finished the last task for the PCbuild9 directory today. I don't think there is much left to do. Now you can all play around with the shiny new VS 2008 and try the PGO builds. I was able to get a speed improvement of about 10% on py3k. Have fun! :)
2007-11-22 07:21:16 -04:00
</VisualStudioPropertySheet>