"Thomas Heller" <thomas.heller(a)ion-tof.com> writes:
> > It would also be nice if we had a distutils compile farm
> > somewhere; oh well, this will probably stay a dream.
> >
>
> I've also thought about this: submit packages (per email, maybe) to
> a server somewhere, and the server runs 'setup.py bdist
> --formats=whatever', and mails the result back. My question is: Can
> this really be made safe?
Seems very unlikely.
Cheers,
M.
--
This is not to say C++ = bad, Lisp = good. It's to say
C++ = bad irrespective of everything else.
-- Alain Picard, comp.lang.lisp
Achim Gaedke <Achim.Gaedke(a)uni-koeln.de> writes:
> I need such things too.
> In my case there is the module initialisation in the *module.c file
> and some 100 of method definitions in another that is included into
> the first.
>
> It would be nice if setup.py can handle this.
There's a bug on sf on this, assigned to me. I'm not likely to get to
it soon, I'm afraid. Patches welcome :)
Cheers,
M.
--
... but I guess there are some things that are so gross you just have
to forget, or it'll destroy something within you. perl is the first
such thing I have known. -- Erik Naggum, comp.lang.lisp
"Thomas Heller" <thomas.heller(a)ion-tof.com> writes:
> > > I can supply a patch if needed.
> >
> > That's the only way this is going to get done...
> Ok, will do.
Cool.
> > I had some crazy ideas to use "gcc -MMD" to create a database of
> > dependencies, so this sort of thing could be done automagically, but
> > this is work.
>
> Even more work than it may seem first, because it has to be done for
> other compilers as well...
Well, perhaps, but I was thinking that you could just send your
package to someone who uses gcc who can then email you the pickled
dependency info back...
Cheers,
M.
--
Worryingly, DEFUN appears to be a function that removes all the
fun from something: after using it all your code is converted
to C++. -- Tim Bradshaw, comp.lang.lisp
"Thomas Heller" <thomas.heller(a)ion-tof.com> writes:
> From: "Michael Hudson" <mwh(a)python.net>
> > Achim Gaedke <Achim.Gaedke(a)uni-koeln.de> writes:
> >
> > > I need such things too.
> >
> > > In my case there is the module initialisation in the *module.c file
> > > and some 100 of method definitions in another that is included into
> > > the first.
> > >
> > > It would be nice if setup.py can handle this.
> >
> > There's a bug on sf on this, assigned to me. I'm not likely to get to
> > it soon, I'm afraid. Patches welcome :)
> >
> IMO we should allow sources to be instances of a SourceFile class
> in addition to strings.
>
> Extension(...,
> sources = SourceFile("spam.c", depends=["spam.h", "spam2.h"]))
You mean
sources = [SourceFile("spam.c", depends=["spam.h", "spam2.h"])])
here, right?
> I can supply a patch if needed.
That's the only way this is going to get done...
I had some crazy ideas to use "gcc -MMD" to create a database of
dependencies, so this sort of thing could be done automagically, but
this is work.
Somebody print "keep it simple, stupid" on a ream of paper and drop it
on my head, please?
Cheers,
M.
--
I've even been known to get Marmite *near* my mouth -- but never
actually in it yet. Vegamite is right out.
UnicodeError: ASCII unpalatable error: vegamite found, ham expected
-- Tim Peters, comp.lang.python
Gregor Hoffleit <gregor(a)hoffleit.de> writes:
> Hi,
>
> I'm trying to build an extension module for the Python22.exe
> distribution from www.python.org. I'm using a current Cygwin environment
> and a trivial Distutils setup.py script.
>
> The build fails, appearently during a sanity check for LONG_BIT. AFAICS,
> the failure is due to differences between the VC compiler used for
> Python22.exe, and the GCC 2.95.4 using in Cygwin:
>
> madonna:1> python setup.py build --compiler=cygwin
Try --compiler=mingw32. What you have there certainly isn't going to
work.
Cheers,
M.
--
I have a feeling that any simple problem can be made arbitrarily
difficult by imposing a suitably heavy administrative process
around the development. -- Joe Armstrong, comp.lang.functional
Hi,
I'm trying to build an extension module for the Python22.exe
distribution from www.python.org. I'm using a current Cygwin environment
and a trivial Distutils setup.py script.
The build fails, appearently during a sanity check for LONG_BIT. AFAICS,
the failure is due to differences between the VC compiler used for
Python22.exe, and the GCC 2.95.4 using in Cygwin:
madonna:1> python setup.py build --compiler=cygwin
running build
running build_ext
building 'leapi' extension
C:\cygwin\bin\gcc.exe -mcygwin -mdll -O -Wall
-I/usr/local/stow/leapi/include -IC:\PROGRAMME\PYTHON22\include -c leapi_wrap.c -o build\temp.win32-2.2\Release\leapi_wrap.o
In file included from C:/PROGRAMME/PYTHON22/include/Python.h:59,
from leapi_wrap.c:35:
C:/PROGRAMME/PYTHON22/include/pyport.h:437: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
error: command 'gcc' failed with exit status 1
Is Distutils supposed to support this situation ? (From what I understand
from other mailing lists, it is possible to setup the Cygwin GCC in
order to build extensions modules compatible with Python22.exe.)
Are there any additional switches to tune Distutils for this situation ?
Thanks,
Gregor
Hello,
I am currently packaging an extension module that uses the glib library.
The correct way to compile such a program is:
gcc `glib-config --cflags` ... -c ... -o ...
That is, the output of "glib-config --cflags" must be near the beginning
of the compilation command (it usually contains -I options).
I tried to use the extra_compile_args argument to Extension's __init__()
method but it only adds arguments to the end of the compilation command.
I looked into Distutils' sources and found that the extra_preargs
argument to UnixCCompiler.compile() would do the trick, but it can't be
set from Extension's __init__() method. When the compile() method is
called in build_ext.py, no extra_preargs is passed, so it always gets
its default value: None.
Currently, I adopted the following "solution": strip the leading -I from
each argument output by "glib-config --cflags" and give it as
include_dirs to Extension.__init__().
This is somewhat ugly since the output of "glib-config --cflags" could
contain arguments that are not include directory specifications. My hack
would fail in such cases.
Is there a better solution I couldn't see? I searched the mailing-list
archive and didn't find anything really satisfactory.
If not, could we consider adding the possibility of specifying
some-arguments-of-any-kind (not only include dirs of macros or whatever)
to be put near the beginning of the compilation command from the setup()
call?
[ BTW, there is a similar issue with linking, but as `glib-config --libs`
is OK at the end of the link command line, extra_link_args does the
trick. However, it would be nice to be able to customize the beginning
if the link command. ]
Thank you for your comments. Here is my current setup.py.
--
Florent