classification
Title: Need to rework the dbm lib/include selection process
Type: behavior Stage: patch review
Components: Build Versions: Python 3.0, Python 3.1, Python 2.7, Python 2.6
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: skip.montanaro Nosy List: doko, hawking, rpetrov, skip.montanaro
Priority: normal Keywords: needs review, patch

Created on 2008-12-08 01:22 by skip.montanaro, last changed 2009-05-01 09:44 by doko. This issue is now closed.

Files
File name Uploaded Description Edit
setup.diff skip.montanaro, 2008-12-08 21:38
0009-By-default-build-dbm-module-with-gdbm_compat-prevent.patch hawking, 2009-03-09 13:50
dbmliborder.diff doko, 2009-04-07 14:40 updated patch
Messages (11)
msg77280 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2008-12-08 01:22
Fixing issue4483 resulted in adding an extra header file check for
gdbm-based header files when the gdbm library was found.  This caused
problems for Roumen Petrov.  In considering the problems he encountered I
decided we probably need to provide users some more flexibility when
deciding which libraries and header files to use when building the dbm
module (or _dbm on 3.0).  For example, the current hard-coded perform checks
in this order: ndbm, gdbm, BerkDB.  What if the system has hdbm installed
but the builder wants to use the BerkDB compatibility API?

This ticket is to track the discussion and come up with a suitable system.
msg77283 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2008-12-08 02:05
Roumen, can you take a look at (and try) the attached patch?  It uses
an environment variable, PYDBMLIBORDER to define the order of libraries
to check for dbm build suitability.  If not specified it defaults to
"ndbm:gdbm:bdb".
msg77314 - (view) Author: Roumen Petrov (rpetrov) * Date: 2008-12-08 15:57
About my environment :
- one is linux :
  a) gdbm library, with header gdbm.h,  without *ndbm.h
  b) "Berkeley DB" many versions but the last is 4.4 I think
- other is cross and native(msys) mingw32 environment 
  only "Berkeley DB" 4.7

I will check later the patch but at first look is expected to fail. Lets
see 
http://svn.python.org/view/python/trunk/Modules/dbmmodule.c?rev=67614&view=auto

 . This module don't include gdbm.h header. I expect linux build to fail
with error "No ndbm.h available!"

I could test patch later when I get access to build environment.

Did you like I to test what is result (linux build) when header gdbm.h
is included in module ?
msg77342 - (view) Author: Roumen Petrov (rpetrov) * Date: 2008-12-08 21:08
I confirm my expectation:
in case 'elif cand == "gdbm":' the if statement for "gdbm.h" has to be
removed. This header don't provide dbm/ndbm compatible
structure/function names.
If setup is without 'if find_file("gdbm.h"...' statement dbm module is
build successfully and test_dbm pass.
msg77348 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2008-12-08 21:38
Roumen> I confirm my expectation:
    Roumen> in case 'elif cand == "gdbm":' the if statement for "gdbm.h" has to be
    Roumen> removed. This header don't provide dbm/ndbm compatible
    Roumen> structure/function names.
    Roumen> If setup is without 'if find_file("gdbm.h"...' statement dbm module is
    Roumen> build successfully and test_dbm pass.

Right.  Dumb move on my part.  New patch attached.

Skip
msg77463 - (view) Author: Roumen Petrov (rpetrov) * Date: 2008-12-09 22:17
ok for patch
msg77469 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2008-12-09 23:03
Thanks Roumen.  Can I get a verdict on this approach from one of the
main Python developers?  I'm thinking a better way to control this
would be to add a --flag to the build command to control the search
order.
msg83379 - (view) Author: Ali Polatel (hawking) Date: 2009-03-09 13:50
Here's how Gentoo and Exherbo does it.
Note this links to gdbm_compat by default and prevents automagic
dependencies.
msg85700 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2009-04-07 14:40
here is an updated patch, adding a new configure option
--with-dbmliborder, and checking the config args in setup.py.

this is the same approach as taken with the --with-system-libffi option.
msg86818 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2009-04-29 17:19
checked in my patch as rev72107 on the trunk. Will apply it for py3k
tomorrow.
msg86876 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2009-05-01 09:44
applied on the py3k branch as well
History
Date User Action Args
2009-05-01 09:44:57dokosetstatus: open -> closed
resolution: accepted
messages: + msg86876
2009-04-29 17:19:21dokosetmessages: + msg86818
2009-04-07 14:40:53dokosetfiles: + dbmliborder.diff
nosy: + doko
messages: + msg85700

2009-03-09 13:50:39hawkingsetfiles: + 0009-By-default-build-dbm-module-with-gdbm_compat-prevent.patch
nosy: + hawking
messages: + msg83379

2008-12-09 23:03:06skip.montanarosetkeywords: + needs review
assignee: skip.montanaro
messages: + msg77469
stage: patch review
2008-12-09 22:17:35rpetrovsetmessages: + msg77463
2008-12-08 21:38:54skip.montanarosetfiles: - setup.diff
2008-12-08 21:38:28skip.montanarosetfiles: + setup.diff
messages: + msg77348
2008-12-08 21:08:59rpetrovsetmessages: + msg77342
2008-12-08 15:57:16rpetrovsetmessages: + msg77314
2008-12-08 02:05:23skip.montanarosetkeywords: + patch
files: + setup.diff
messages: + msg77283
2008-12-08 01:23:38skip.montanarosetpriority: normal
nosy: + rpetrov
type: behavior
components: + Build
versions: + Python 2.6, Python 3.0, Python 3.1, Python 2.7
2008-12-08 01:22:50skip.montanarocreate