On 2006/08/30 18:14, Matthias Klose <[EMAIL PROTECTED]> wrote:
> no, find out why the module isn't built. it's not a problem on the
> debian buildd's. see
> http://buildd.debian.org/build.php?arch=&pkg=python2.5
OK, after a debugging session, I found out why. It seems to be an
upstream bug in distutils. See
python2.5-2.5~c1/Lib/distutils/command/build_ext.py line 188+:
if string.find(sys.executable, sys.exec_prefix) != -1:
# building third party extensions
self.library_dirs.append(os.path.join(sys.prefix, "lib",
"python" +
get_python_version(),
"config"))
else:
# building python standard extensions
self.library_dirs.append('.')
This code is executed only in the shared build. The if clause is here
to determine whether we're running a correctly installed python or
whether we're running python from its source tree. In our case (since
we're building python itself atm), the condition *must* evaluate to
false. However, this exact check looks very clumsy.
On my build system, sys.executable ==
'/usr/src/debian/build/python2.5-2.5~c1/build-shared/python',
sys.exec_prefix == '/usr', i.e. the condition is true and distutils
thinks it's running on an already installed python distribution. The
reason is that I'm building below the 'install prefix' directory (in
/usr/src/...).
In contrast, on the Debian buildd machines, this is performed in
/build/buildd/.... which does not trigger the distutils bug.
Since the Debian policy does not impose restrictions on where you
build packages (and my choice "/usr/src" does not look unusual to me),
I believe my bug report is valid.
Max
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
