mirror of
https://github.com/python/cpython
synced 2026-09-29 12:10:30 +03:00
#3791: remove last traces of bsddb.
This commit is contained in:
parent
b54d801280
commit
1158a33fab
18 changed files with 26 additions and 292 deletions
|
|
@ -12,7 +12,6 @@
|
|||
<excludeprojects>
|
||||
<include name="_tkinter.vcproj" />
|
||||
<include name="bz2.vcproj" />
|
||||
<include name="_bsddb.vcproj" />
|
||||
<include name="_sqlite3.vcproj" />
|
||||
<include name="_ssl.vcproj" />
|
||||
</excludeprojects>
|
||||
|
|
|
|||
|
|
@ -137,9 +137,6 @@ Source: libs\_testcapi.lib; DestDir: {app}\libs; CopyMode: alwaysoverwrite; Comp
|
|||
Source: DLLs\_tkinter.pyd; DestDir: {app}\DLLs; CopyMode: alwaysoverwrite; Components: tk
|
||||
Source: libs\_tkinter.lib; DestDir: {app}\libs; CopyMode: alwaysoverwrite; Components: tk
|
||||
|
||||
Source: DLLs\bsddb.pyd; DestDir: {app}\DLLs; CopyMode: alwaysoverwrite; Components: main
|
||||
Source: libs\bsddb.lib; DestDir: {app}\libs; CopyMode: alwaysoverwrite; Components: main
|
||||
|
||||
Source: DLLs\mmap.pyd; DestDir: {app}\DLLs; CopyMode: alwaysoverwrite; Components: main
|
||||
Source: libs\mmap.lib; DestDir: {app}\libs; CopyMode: alwaysoverwrite; Components: main
|
||||
|
||||
|
|
|
|||
|
|
@ -1753,11 +1753,6 @@ item: Install File
|
|||
Destination=%MAINDIR%\DLLs\_socket.pyd
|
||||
Flags=0000000000000010
|
||||
end
|
||||
item: Install File
|
||||
Source=.\_bsddb.pyd
|
||||
Destination=%MAINDIR%\DLLs\_bsddb.pyd
|
||||
Flags=0000000000000010
|
||||
end
|
||||
item: Install File
|
||||
Source=.\bz2.pyd
|
||||
Destination=%MAINDIR%\DLLs\bz2.pyd
|
||||
|
|
@ -1850,11 +1845,6 @@ item: Install File
|
|||
Destination=%MAINDIR%\libs\_socket.lib
|
||||
Flags=0000000000000010
|
||||
end
|
||||
item: Install File
|
||||
Source=.\_bsddb.lib
|
||||
Destination=%MAINDIR%\libs\_bsddb.lib
|
||||
Flags=0000000000000010
|
||||
end
|
||||
item: Install File
|
||||
Source=.\bz2.lib
|
||||
Destination=%MAINDIR%\libs\bz2.lib
|
||||
|
|
@ -1939,14 +1929,6 @@ item: Install File
|
|||
end
|
||||
item: Remark
|
||||
end
|
||||
item: Install File
|
||||
Source=..\lib\bsddb\*.py
|
||||
Destination=%MAINDIR%\Lib\bsddb
|
||||
Description=Berkeley database package
|
||||
Flags=0000000100000010
|
||||
end
|
||||
item: Remark
|
||||
end
|
||||
item: Install File
|
||||
Source=..\lib\compiler\*.py
|
||||
Destination=%MAINDIR%\Lib\compiler
|
||||
|
|
|
|||
|
|
@ -138,82 +138,6 @@ bz2
|
|||
All of this managed to build bzip2-1.0.3\libbz2.lib, which the Python
|
||||
project links in.
|
||||
|
||||
|
||||
_bsddb
|
||||
To use the version of bsddb that Python is built with by default, invoke
|
||||
(in the dist directory)
|
||||
|
||||
svn export http://svn.python.org/projects/external/db-4.4.20
|
||||
|
||||
|
||||
Then open a VS.NET 2003 shell, and invoke:
|
||||
|
||||
devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Release /project db_static
|
||||
|
||||
and do that a second time for a Debug build too:
|
||||
|
||||
devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static
|
||||
|
||||
Alternatively, if you want to start with the original sources,
|
||||
go to Sleepycat's download page:
|
||||
http://www.sleepycat.com/downloads/releasehistorybdb.html
|
||||
|
||||
and download version 4.4.20.
|
||||
|
||||
With or without strong cryptography? You can choose either with or
|
||||
without strong cryptography, as per the instructions below. By
|
||||
default, Python is built and distributed WITHOUT strong crypto.
|
||||
|
||||
Unpack the sources; if you downloaded the non-crypto version, rename
|
||||
the directory from db-4.4.20.NC to db-4.4.20.
|
||||
|
||||
Now apply any patches that apply to your version.
|
||||
|
||||
Open
|
||||
dist\db-4.4.20\docs\index.html
|
||||
|
||||
and follow the "Windows->Building Berkeley DB with Visual C++ .NET"
|
||||
instructions for building the Sleepycat
|
||||
software. Note that Berkeley_DB.dsw is in the build_win32 subdirectory.
|
||||
Build the "db_static" project, for "Release" mode.
|
||||
|
||||
To run extensive tests, pass "-u bsddb" to regrtest.py. test_bsddb3.py
|
||||
is then enabled. Running in verbose mode may be helpful.
|
||||
|
||||
XXX The test_bsddb3 tests don't always pass, on Windows (according to
|
||||
XXX me) or on Linux (according to Barry). (I had much better luck
|
||||
XXX on Win2K than on Win98SE.) The common failure mode across platforms
|
||||
XXX is
|
||||
XXX DBAgainError: (11, 'Resource temporarily unavailable -- unable
|
||||
XXX to join the environment')
|
||||
XXX
|
||||
XXX and it appears timing-dependent. On Win2K I also saw this once:
|
||||
XXX
|
||||
XXX test02_SimpleLocks (bsddb.test.test_thread.HashSimpleThreaded) ...
|
||||
XXX Exception in thread reader 1:
|
||||
XXX Traceback (most recent call last):
|
||||
XXX File "C:\Code\python\lib\threading.py", line 411, in __bootstrap
|
||||
XXX self.run()
|
||||
XXX File "C:\Code\python\lib\threading.py", line 399, in run
|
||||
XXX apply(self.__target, self.__args, self.__kwargs)
|
||||
XXX File "C:\Code\python\lib\bsddb\test\test_thread.py", line 268, in
|
||||
XXX readerThread
|
||||
XXX rec = c.next()
|
||||
XXX DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed
|
||||
XXX to resolve a deadlock')
|
||||
XXX
|
||||
XXX I'm told that DBLockDeadlockError is expected at times. It
|
||||
XXX doesn't cause a test to fail when it happens (exceptions in
|
||||
XXX threads are invisible to unittest).
|
||||
|
||||
Building for Win64:
|
||||
- open a VS.NET 2003 command prompt
|
||||
- run the SDK setenv.cmd script, passing /RETAIL and the target
|
||||
architecture (/SRV64 for Itanium, /X64 for AMD64)
|
||||
- build BerkeleyDB with the solution configuration matching the
|
||||
target ("Release IA64" for Itanium, "Release AMD64" for AMD64), e.g.
|
||||
devenv db-4.4.20\build_win32\Berkeley_DB.sln /build "Release AMD64" /project db_static /useenv
|
||||
|
||||
_sqlite3
|
||||
Python wrapper for SQLite library.
|
||||
|
||||
|
|
@ -363,7 +287,7 @@ Setting up the environment
|
|||
Extension modules
|
||||
|
||||
To build those extension modules which require external libraries
|
||||
(_tkinter, bz2, _bsddb, _sqlite3, _ssl) you can follow the instructions
|
||||
(_tkinter, bz2, _sqlite3, _ssl) you can follow the instructions
|
||||
for the Visual Studio build above, with a few minor modifications. These
|
||||
instructions have only been tested using the sources in the Python
|
||||
subversion repository - building from original sources should work, but
|
||||
|
|
@ -386,19 +310,6 @@ Extension modules
|
|||
bz2
|
||||
No changes are needed
|
||||
|
||||
_bsddb
|
||||
The file db.build should be copied from the Python PCBuild directory
|
||||
to the directory db-4.4.20\build_win32.
|
||||
|
||||
The file db_static.vcproj in db-4.4.20\build_win32 should be edited to
|
||||
remove the string "$(SolutionDir)" - this occurs in 2 places, only
|
||||
relevant for 64-bit builds. (The edit is required as otherwise, nant
|
||||
wants to read the solution file, which is not in a suitable form).
|
||||
|
||||
The bsddb library can then be build with the command
|
||||
nant -buildfile:db.build all
|
||||
run from the db-4.4.20\build_win32 directory.
|
||||
|
||||
_sqlite3
|
||||
No changes are needed. However, in order for the tests to succeed, a
|
||||
copy of sqlite3.dll must be downloaded, and placed alongside
|
||||
|
|
|
|||
|
|
@ -48,30 +48,6 @@
|
|||
Name="externalsDir"
|
||||
Value="..\..\.."
|
||||
/>
|
||||
<UserMacro
|
||||
Name="bsddbDir"
|
||||
Value="$(bsddb44Dir)"
|
||||
/>
|
||||
<UserMacro
|
||||
Name="bsddbDepLibs"
|
||||
Value="$(bsddb44DepLibs)"
|
||||
/>
|
||||
<UserMacro
|
||||
Name="bsddb44Dir"
|
||||
Value="$(externalsDir)\db-4.4.20\build_win32"
|
||||
/>
|
||||
<UserMacro
|
||||
Name="bsddb44DepLibs"
|
||||
Value=""
|
||||
/>
|
||||
<UserMacro
|
||||
Name="bsddb45Dir"
|
||||
Value="$(externalsDir)\db-4.5.20.x\build_windows"
|
||||
/>
|
||||
<UserMacro
|
||||
Name="bsddb45DepLibs"
|
||||
Value="ws2_32.lib"
|
||||
/>
|
||||
<UserMacro
|
||||
Name="sqlite3Dir"
|
||||
Value="$(externalsDir)\sqlite-3.5.9"
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ Optional modules:
|
|||
Where I've been able to locate the required 3rd party packages already
|
||||
ported to OS/2, I've built and included them.
|
||||
|
||||
These include ncurses (_curses, _curses_panel), BSD DB (bsddb185),
|
||||
These include ncurses (_curses, _curses_panel),
|
||||
GNU GDBM (gdbm, dbm), zlib (zlib), GNU Readline (readline), and GNU UFC
|
||||
(crypt).
|
||||
|
||||
|
|
@ -150,10 +150,6 @@ Upstream source patches:
|
|||
|
||||
No updates to the Python 2.6 release have become available.
|
||||
|
||||
Eberhard Mattes' EMXFIX04 update to his EMX 0.9d tools suite includes
|
||||
bug fixes for the BSD DB library. The bsddb module included in this
|
||||
port incorporates these fixes.
|
||||
|
||||
Library and other distributed Python code:
|
||||
|
||||
The Python standard library lives in the Lib directory. All the standard
|
||||
|
|
@ -326,7 +322,6 @@ Procedure
|
|||
GNU UltraFast Crypt HAVE_UFC
|
||||
Tcl/Tk HAVE_TCLTK (not known to work)
|
||||
GNU Readline HAVE_GREADLINE
|
||||
BSD DB (v1.85) HAVE_BSDDB
|
||||
ncurses HAVE_NCURSES
|
||||
GNU gdbm HAVE_GDBM
|
||||
libbz2 HAVE_BZ2
|
||||
|
|
@ -388,52 +383,23 @@ EMXVIEW.ZIP archive as part of the complete EMX development tools suite).
|
|||
Because of other side-effects I have modified the test_fcntl.py test
|
||||
script to deactivate the exercising of the missing functionality.
|
||||
|
||||
4. the PyBSDDB3 module has been imported into the Python standard
|
||||
library, with the intent of superceding the BSDDB 1.85 module (bsddb).
|
||||
As I don't yet have a satisfactory port of Sleepcat's more recent DB
|
||||
library (3.3.x/4.0.x/4.1.x), I haven't included a binary of this
|
||||
module. I have left the Python part of the PyBSDDB package in this
|
||||
distribution for completeness.
|
||||
|
||||
5. As a consequence of the PyBSDDB3 module being imported, the former
|
||||
BSD DB (bsddb) module, linked against the DB v1.85 library from EMX,
|
||||
has been renamed bsddb185. The bsddb185 module will not be built by
|
||||
default on most platforms, but in the absence of a PyBSDDB3 module I
|
||||
have retained it in the EMX port.
|
||||
|
||||
Version 1.85 of the DB library is widely known to have bugs, although
|
||||
some patches have become available (and are incorporated into the
|
||||
included bsddb185 module). Unless you have problems with software
|
||||
licenses which would rule out GDBM (and the dbm module because it is
|
||||
linked against the GDBM library) or need it for file format compatibility,
|
||||
you may be better off deleting it and relying on GDBM.
|
||||
|
||||
Any code you have which uses the v1.85 bsddb module can be modified to
|
||||
use the renamed module by changing
|
||||
|
||||
import bsddb
|
||||
|
||||
to
|
||||
|
||||
import bsddb185 as bsddb
|
||||
|
||||
6. The readline module has been linked against ncurses rather than the
|
||||
4. The readline module has been linked against ncurses rather than the
|
||||
termcap library supplied with EMX.
|
||||
|
||||
7. I have configured this port to use "/" as the preferred path separator
|
||||
5. I have configured this port to use "/" as the preferred path separator
|
||||
character, rather than "\" ('\\'), in line with the convention supported
|
||||
by EMX. Backslashes are still supported of course, and still appear in
|
||||
unexpected places due to outside sources that don't get normalised.
|
||||
|
||||
8. While the DistUtils components are now functional, other
|
||||
6. While the DistUtils components are now functional, other
|
||||
packaging/binary handling tools and utilities such as those included in
|
||||
the Demo and Tools directories - freeze in particular - are unlikely to
|
||||
work. If you do get them going, I'd like to know about your success.
|
||||
|
||||
9. I haven't set out to support the [BEGIN|END]LIBPATH functionality
|
||||
7. I haven't set out to support the [BEGIN|END]LIBPATH functionality
|
||||
supported by one of the earlier ports (Rush's??). If it works let me know.
|
||||
|
||||
10. As a result of the limitations imposed by EMX's library routines, the
|
||||
8. As a result of the limitations imposed by EMX's library routines, the
|
||||
standard extension module pwd only synthesises a simple passwd database,
|
||||
and the grp module cannot be supported at all.
|
||||
|
||||
|
|
@ -511,11 +477,7 @@ strftime routine - I'm looking into using one from FreeBSD, but its not
|
|||
ready yet.
|
||||
|
||||
16. I have successfully built this port with Andy Zabolotny's ports of
|
||||
pgcc 2.95 and gcc 3.2.1, in addition to EM's gcc 2.8.1. To use the
|
||||
bsddb185 module with the gcc 3.2.1 build, I had to recompile the DB library
|
||||
with gcc 3.2.1 - I don't know why, but trying to import the module built
|
||||
against a DB library compiled with gcc 2.8.1 would result in a SYS3175
|
||||
error.
|
||||
pgcc 2.95 and gcc 3.2.1, in addition to EM's gcc 2.8.1.
|
||||
|
||||
I have not attempted to compile Python with any version of gcc prior to
|
||||
v2.8.1.
|
||||
|
|
|
|||
|
|
@ -408,20 +408,6 @@ binascii.obj: $(PY_INCLUDE)\abstract.h $(PY_INCLUDE)\ceval.h $(PY_INCLUDE)\class
|
|||
$(PY_INCLUDE)\sliceobject.h $(PY_INCLUDE)\stringobject.h \
|
||||
$(PY_INCLUDE)\sysmodule.h $(PY_INCLUDE)\traceback.h $(PY_INCLUDE)\tupleobject.h
|
||||
|
||||
bsddbmodule.obj: $(PY_INCLUDE)\abstract.h $(PY_INCLUDE)\ceval.h \
|
||||
$(PY_INCLUDE)\classobject.h $(PY_INCLUDE)\cobject.h $(PY_INCLUDE)\complexobject.h \
|
||||
pyconfig.h $(PY_INCLUDE)\dictobject.h $(PY_INCLUDE)\fileobject.h \
|
||||
$(PY_INCLUDE)\floatobject.h $(PY_INCLUDE)\funcobject.h $(PY_INCLUDE)\import.h \
|
||||
$(PY_INCLUDE)\intobject.h $(PY_INCLUDE)\intrcheck.h $(PY_INCLUDE)\listobject.h \
|
||||
$(PY_INCLUDE)\longobject.h $(PY_INCLUDE)\methodobject.h \
|
||||
$(PY_INCLUDE)\modsupport.h $(PY_INCLUDE)\moduleobject.h $(PY_INCLUDE)\mymalloc.h \
|
||||
$(PY_INCLUDE)\myproto.h $(PY_INCLUDE)\object.h $(PY_INCLUDE)\objimpl.h \
|
||||
$(PY_INCLUDE)\pydebug.h $(PY_INCLUDE)\pyerrors.h $(PY_INCLUDE)\pyfpe.h \
|
||||
$(PY_INCLUDE)\pystate.h $(PY_INCLUDE)\python.h $(PY_INCLUDE)\pythonrun.h \
|
||||
$(PY_INCLUDE)\rangeobject.h $(PY_INCLUDE)\sliceobject.h \
|
||||
$(PY_INCLUDE)\stringobject.h $(PY_INCLUDE)\sysmodule.h $(PY_INCLUDE)\traceback.h \
|
||||
$(PY_INCLUDE)\tupleobject.h
|
||||
|
||||
cmathmodule.obj: $(PY_INCLUDE)\abstract.h $(PY_INCLUDE)\ceval.h \
|
||||
$(PY_INCLUDE)\classobject.h $(PY_INCLUDE)\cobject.h $(PY_INCLUDE)\complexobject.h \
|
||||
pyconfig.h $(PY_INCLUDE)\dictobject.h $(PY_INCLUDE)\fileobject.h \
|
||||
|
|
|
|||
|
|
@ -360,14 +360,6 @@ binascii.obj: abstract.h ceval.h classobject.h cobject.h complexobject.h \
|
|||
pythonrun.h rangeobject.h sliceobject.h stringobject.h sysmodule.h \
|
||||
traceback.h tupleobject.h
|
||||
|
||||
bsddbmodule.obj: abstract.h ceval.h classobject.h cobject.h complexobject.h \
|
||||
pyconfig.h dictobject.h fileobject.h floatobject.h funcobject.h \
|
||||
import.h intobject.h intrcheck.h listobject.h longobject.h \
|
||||
methodobject.h modsupport.h moduleobject.h mymalloc.h myproto.h \
|
||||
object.h objimpl.h pydebug.h pyerrors.h pyfpe.h pystate.h python.h \
|
||||
pythonrun.h rangeobject.h sliceobject.h stringobject.h sysmodule.h \
|
||||
traceback.h tupleobject.h
|
||||
|
||||
cmathmodule.obj: abstract.h ceval.h classobject.h cobject.h complexobject.h \
|
||||
pyconfig.h dictobject.h fileobject.h floatobject.h funcobject.h \
|
||||
import.h intobject.h intrcheck.h listobject.h longobject.h \
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue