I need to build a C extension consisting of several C code files, one
of which needs to be compiled with different compiler options. There
doesn't seem to be a standard way to do this.
As a workaround I added a dummy extension that uses that file, and
specified the necessary compiler options for that extension. Then I
removed the source file from the file list of the real extension and
replaced it by an entry in extra_objects. The idea is the re-use the
version compiled for the dummy extension module.
However, there are two problems:
1) The documentation for extra_objects states that "These files must
not have extensions, as the default extension for the compiler is
used." That would be nice, but isn't true: on my Mac, the required
".o" is not added.
2) The object file I wish to add has been created in "build/
temp.macosx-10.3-fat-2.5", but this directory is machine-specific. I
need to construct this path in a portable way - but how?
Did anyone already solve these problems, or find another solution?
Thanks in advance,
I just got an error trying to upgrade SilverCity from easy_install:
File "/usr/lib/python2.4/site-packages/setuptools-0.6c5-py2.4.egg/setuptools/command/easy_install.py", line 1462, in is_python
compile(text, filename, 'exec')
TypeError: compile() expected string without null bytes
You can reproduce it easily:
>>> from setuptools.command.easy_install import is_python
The fix is simply to add TypeError to the except clause along with
-- Matt Good
Automatic installation of eggs required by an egg extra doesn't seem to
work for a recipe used with zc.buildout as documented for eggs in general:
Suppose myrecipe has two entry points, the "fancy" one employing
yourrecipe. Now if I declare yourrecipe as an extra requirement only to be
installed if the "fancy" entry point is used to install any buildout part:
"default = myrecipe.foo:Recipe",
"fancy = myrecipe.bar:Recipe [bar_extra]",
and use myrecipe I get a pkg_resources.DistributionNotFound error
concerning yourrecipe. It sort of works if I manually copy the yourrecipe
egg to the eggs directory beforehand, though.
Is this a real bug, or are recipes supposed to be so simple as to not need
The more I manage the third-party packages I have installed with easy_install,
the more I like that I never have to fiddle around in the file system. (Except
when I want to free the space that a no-longer needed package consumes,
"easy_install -m <package-name>" works fine).
However (since I'm playing around with support for eggs in py2exe), it is not
possible to reinstall an already installed (by it multi-version or not) package
in zipped or unzipped form by using easy_install. I always have to delete the package
in the file-system and then call 'easy_install -z|-Z package'.
Distutils create dynamic library for a C extension in `build/...'
directory. This makes it impossible to run program without
installing it, which I find very important for developing. Ideally,
process should look like this:
edit Python code -> test (uninstalled);
edit C code -> ./setup.by build -> test (uninstalled).
This is all possible if I create a symbolic link from build
directory to the sources. Then extension module can be imported
normally and everything is like it was with all code limited to
Is it possible in some standard (and preferably portable) way with
distutils? Is it already done?
I'd like to know if there is a source egg of ctypes
(for Python 2.4.x) that can be built and deployed via
I need to be able to cross compile ctypes from an
i686Linux box targeting both i686 and ppc Linux's. I'd
like to deploy it with a python app that is also being
built/pkg as an egg.
I searched the archives, but found no pointers.
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
At 03:41 AM 2/14/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
>On top of PyPI and Cheesecake I've build a Cheesecake service - a
>service which automatically downloads and scores new package releases.
>It is available at this address: http://pypi.pycheesecake.org/pypi/ .
>Probably of most interest here is the easy_installability page
>(http://pypi.pycheesecake.org/pypi/easy_installability) which shows
>releases which are listed on PyPI, yet still can't be easy_installed.
>I'm open to any suggestions on how this service can be improved.
More information about *how* the installation failed would be useful for
package authors to see at a glance what's wrong. Right now, it's too easy
to dismiss it as a peculiarity of your installation. Being able to click
through and see the log/tracebacks would probably make it more likely that
an author spots the problem(s).
I know that distutils' purpose is not to re-implement libtool, but.. it seems
that it is a common problem that one wants to ship several extension modules
which rely on the same code. E.g. we have several image processing functions
split across several extension modules (written in C++), and we need them all
to know about our PythonImage class. (E.g. PythonImage::subImage(...) or the
A natural way to solve this is to compile pythonimage.cxx into a small shared
library which the extension modules link against. So far, it seems that all
projects which have this problem use Extension(...) to build a shared library
or call make / do whatever custom hacks were necessary for them. (One source
of information were the answers to David Abrahams question some years ago:
http://mail.python.org/pipermail/distutils-sig/2002-October/002966.html and I
also asked on C++-sig lately:
Would it be possible to add a distutils.SharedLibrary class? (OK, would
someone be willing to provide the code? ;-) )
Ciao, / /
/ / ANS
For a long time, I have been annoyed by distutils behavior concerning
"scripts": I always put
into the first line in order to let the incredibly useful "env" program start
the right python version.
I know that it is quite evil to hardcode /usr/bin/python
or /usr/local/bin/python; I have seen dozens of #! hacks for finding e.g.
perl, and I was delighted to find /usr/bin/env, which solves the problem once
and for all. (And yes - it is always in /usr/bin/! ;-) )
Now distutils tries to be intelligent and "destroys" my nice #! lines, which
can be quite evil in complex setups, e.g. when you share your home directory
via NFS (or rsync/unison) between several environments with different python
installations. Furthermore, we are using the "module" system here at our
university, so that I can dynamically choose between half a dozen python
versions ("module" manages your PATH variables). Replacing the python path
turns nice, pure python scrips into platform-specific programs as you can see
meine@kogspc12:~ head -n1 ~/vigra/interactive/build/scripts-2.4/pyterm
Note the SuSE-9.0 exec-prefix in the path; we are using several Linux and
Solaris versions here:
meine@kogspc12:~/tmp/vi3build -> ls -1 /software/python-2.4.4/*/bin/python
I see that distutils as it is now does the right thing
* on Windows systems,
* on any system where /usr/bin/env is missing, or
* when the source file has a #! with a broken path.
What I propose is a minimal invasive change which keeps /usr/bin/env iff it is
in the #! line *and* exists on the current system. (A more brave change
would be to always use /usr/bin/env if it exists, but I think that is a topic
open for discussion.) Attached you'll find a patch which implements this; I
did not yet update tests/test_build_scripts.py however.
Ciao, / /
/ / ANS
At 02:35 PM 2/13/2007 -0800, Ronald Oussoren wrote:
>The attached patched replaces pkg_resources._macosx_vers by a function
>that directly parses the relevant XML file instead of using sw_vers. The
>patch is an svn diff relative to the trunk.
>The main reason I prefer this version is that I'm debugging some C code in
>a project using setuptools using command-line gdb (who needs IDE's?) and I
>often (but not always) get I/O errors when reading from a pipe to a
>forked-off process when running python from gdb. With this patch
>pkg_resources no longer forks of processes and gdb is happy.
>When you're not using gdb there's little reason to prefer this version
>over the original one.
Your patch uses plistlib, which doesn't appear to be part of the Python