Re: [Numpy-discussion] [Distutils] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

>> I'm not talking about in place installs, I'm talking about e.g. building a >> wheel and then tweaking one file and rebuilding -- traditionally build >> systems go to some effort to keep track of intermediate artifacts and reuse >> them across builds when possible, but if you always copy the sour

Re: [Numpy-discussion] [Distutils] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

On Nov 2, 2015 6:51 PM, "Robert Collins" wrote: > > On 3 November 2015 at 14:57, Nathaniel Smith wrote: > > [Adding distutils-sig to the CC as a heads-up. The context is that > > numpy is looking at deprecating the use of 'python setup.py install' > > and enforcing the use of 'pip install .' inst

Re: [Numpy-discussion] Distutils - way to check validity of compiler flag?

Hi, On Mon, May 12, 2014 at 12:50 PM, Robert McGibbon wrote: > In a couple of my projects, we check for flags by compiling little test > files -- autotools style -- to check for SSE, OpenMP, etc. See e.g. > https://github.com/rmcgibbo/mdtraj/blob/master/setup.py#L215 > > If anyone has a better so

Re: [Numpy-discussion] Distutils - way to check validity of compiler flag?

In a couple of my projects, we check for flags by compiling little test files -- autotools style -- to check for SSE, OpenMP, etc. See e.g. https://github.com/rmcgibbo/mdtraj/blob/master/setup.py#L215 If anyone has a better solution, I'm all ears. -Robert On Mon, May 12, 2014 at 12:24 PM, Matth

[Numpy-discussion] Distutils - way to check validity of compiler flag?

Hi, I'm sorry to ask this, I guess I should know - but is there any way in disutils or numpy distutils to check whether a compiler flag is valid before doing extension building? I'm thinking of something like this, to check whether the compiler can handle '-fopenmp': have_openmp = check_compiler

[Numpy-discussion] distutils seems to pick the wrong fortran compiler flags

Hi, I'm using f2py shipping with EPD 32 bit on 64 bit Mac OS 10.8. The command "f2py -c -m plot3d --fcompiler=gnu95 plot3d.f90" compiles the objects files in 32 bit, which is good, but fails at the linkage step with a "file was built for i386 which is not the architecture being linked (x86_64)" w

Re: [Numpy-discussion] distutils & C++ & Fortran

On Tue, Oct 16, 2012 at 9:56 PM, Pauli Virtanen wrote: > Charles R Harris gmail.com> writes: >> On Sun, Oct 14, 2012 at 11:53 AM, Pauli Virtanen iki.fi> wrote: >> Hi, >> I'd like to link both C++ and Fortran code into a single >> Python extension, using numpy.distutils (for scipy.special). >> B

Re: [Numpy-discussion] distutils & C++ & Fortran

Charles R Harris gmail.com> writes: > On Sun, Oct 14, 2012 at 11:53 AM, Pauli Virtanen iki.fi> wrote: > Hi, > I'd like to link both C++ and Fortran code into a single > Python extension, using  numpy.distutils (for scipy.special). > But it seems the distutils-based tools actually cannot do this?

Re: [Numpy-discussion] distutils & C++ & Fortran

On Sun, Oct 14, 2012 at 11:53 AM, Pauli Virtanen wrote: > Hi, > > I'd like to link both C++ and Fortran code into a single > Python extension, using numpy.distutils (for scipy.special). > > But it seems the distutils-based tools actually cannot do this? > Does someone know if there's a way to wo

[Numpy-discussion] distutils & C++ & Fortran

Hi, I'd like to link both C++ and Fortran code into a single Python extension, using numpy.distutils (for scipy.special). But it seems the distutils-based tools actually cannot do this? Does someone know if there's a way to work around this? -- Pauli Virtanen

Re: [Numpy-discussion] distutils: compiler used by add_library

Hi Matyáš, On Wed, Aug 29, 2012 at 3:20 AM, Matyáš Novák wrote: > Hi, > I wrote extension some numerical extension for python, that requires > compiling > and linking additional fortran sources. I find out, that these libraries > can be easily added > using config.add_library() function, but ther

[Numpy-discussion] distutils: compiler used by add_library

Hi, I wrote extension some numerical extension for python, that requires compiling and linking additional fortran sources. I find out, that these libraries can be easily added using config.add_library() function, but there is a problem. The --fcompiler command doesn't propagate to the stage where

[Numpy-discussion] distutils and SWIG problem

Dear Numpy users, I've been trying to compile Scikits ANN (http://projects.scipy.org/scikits/wiki/AnnWrapper) with Python 2.7.1, numpy 1.6.0, and SWIG 2.0.3 but the compilation breaks down down with this error: running install running bdist_egg running egg_info running build_src build_src buil

Re: [Numpy-discussion] distutils

On Tue, Sep 7, 2010 at 14:12, Charles Doutriaux wrote: >  Hi, > > I'm using distutils to build extensions written in C. > > I noticed that lately (it seems to be python 2.7 related) whenever I > touch 1 C file, ALL the C files are rebuilt. > Since I have a lot of C code, it takes a lot of time for

[Numpy-discussion] distutils

Hi, I'm using distutils to build extensions written in C. I noticed that lately (it seems to be python 2.7 related) whenever I touch 1 C file, ALL the C files are rebuilt. Since I have a lot of C code, it takes a lot of time for nothing. Any idea why this is happening? Do I need to set somethi

Re: [Numpy-discussion] distutils issue - python 3.1 on windows

Wed, 04 Aug 2010 23:34:15 +0800, Ralf Gommers wrote: [clip] > I haven't started using py3k yet so I'm still a bit fuzzy about bytes > vs string. But it's easy to try in the interpreter: > import re RE_VERSION = re.compile('(\d+\.\d+(\.\d+)*)') In the Python 3.1 version I have, this lin

Re: [Numpy-discussion] distutils issue - python 3.1 on windows

On Wed, Aug 4, 2010 at 6:25 AM, Pauli Virtanen wrote: > Mon, 02 Aug 2010 23:48:52 +0800, Ralf Gommers wrote: > > I'm trying to get building to work with Python 3.1 under Wine on OS X. > > The first thing you run into is a python distutils problem, which is > > fixed by replacing line 379 of cygw

Re: [Numpy-discussion] distutils issue - python 3.1 on windows

Mon, 02 Aug 2010 23:48:52 +0800, Ralf Gommers wrote: > I'm trying to get building to work with Python 3.1 under Wine on OS X. > The first thing you run into is a python distutils problem, which is > fixed by replacing line 379 of cygwinccompiler.py with > result = RE_VERSION.search(str(out_str

Re: [Numpy-discussion] distutils issue - python 3.1 on windows

On 08/03/2010 02:57 AM, Pauli Virtanen wrote: > Mon, 02 Aug 2010 12:52:12 -0500, Robert Kern wrote: > [clip] >> I believe we avoided the inspect module because it is quite expensive to >> import. It may not matter inside numpy.distutils, but be wary of >> "fixing" things to use inspect elsewhere. I

Re: [Numpy-discussion] distutils issue - python 3.1 on windows

Mon, 02 Aug 2010 12:52:12 -0500, Robert Kern wrote: [clip] > I believe we avoided the inspect module because it is quite expensive to > import. It may not matter inside numpy.distutils, but be wary of > "fixing" things to use inspect elsewhere. It would be worth extracting > the commonly-used piece

Re: [Numpy-discussion] distutils issue - python 3.1 on windows

On Mon, Aug 2, 2010 at 12:48, Pauli Virtanen wrote: > Mon, 02 Aug 2010 23:48:52 +0800, Ralf Gommers wrote: >> I'm trying to get building to work with Python 3.1 under Wine on OS X. >> The first thing you run into is a python distutils problem, which is >> fixed by replacing line 379 of  cygwinccom

Re: [Numpy-discussion] distutils issue - python 3.1 on windows

Mon, 02 Aug 2010 23:48:52 +0800, Ralf Gommers wrote: > I'm trying to get building to work with Python 3.1 under Wine on OS X. > The first thing you run into is a python distutils problem, which is > fixed by replacing line 379 of cygwinccompiler.py with > result = RE_VERSION.search(str(out_str

[Numpy-discussion] distutils issue - python 3.1 on windows

Hi, I'm trying to get building to work with Python 3.1 under Wine on OS X. The first thing you run into is a python distutils problem, which is fixed by replacing line 379 of cygwinccompiler.py with result = RE_VERSION.search(str(out_string)) The next thing I run into is a numpy.distutils is

Re: [Numpy-discussion] distutils and Framework

2010/6/17 Charles سمير Doutriaux : > Hi, > > I noticed that when using a Framework based python under Mac. > > numpy nicely gets installed into the Python.Framework directory by default. > > But then if I use: > > from numpy.distutils.core import setup, Extension > > It installed under the regular:

[Numpy-discussion] distutils and Framework

Hi, I noticed that when using a Framework based python under Mac. numpy nicely gets installed into the Python.Framework directory by default. But then if I use: from numpy.distutils.core import setup, Extension It installed under the regular: ${prefix}/lib/python-2.6/site-packages which force

Re: [Numpy-discussion] distutils problem with NumPy-1.4 & Py-2.7a3 (Snow Leopard)

On Wed, Feb 24, 2010 at 11:21 AM, Bruce Southey wrote: > On 02/23/2010 04:47 PM, Robert Kern wrote: >> >> On Tue, Feb 23, 2010 at 13:18, Tom Loredo >>  wrote: >> >>> >>> Hi- >>> >>> I've been testing Python-2.7a3 on Mac OS 10.6.2.  NumPy-1.4.0 will >>> not install; it appears something has changed

Re: [Numpy-discussion] distutils problem with NumPy-1.4 & Py-2.7a3 (Snow Leopard)

On 02/23/2010 04:47 PM, Robert Kern wrote: > On Tue, Feb 23, 2010 at 13:18, Tom Loredo wrote: > >> Hi- >> >> I've been testing Python-2.7a3 on Mac OS 10.6.2. NumPy-1.4.0 will >> not install; it appears something has changed within distutils that >> breaks it: >> File >> "/Volumes/System/Us

Re: [Numpy-discussion] distutils problem with NumPy-1.4 & Py-2.7a3 (Snow Leopard)

On Tue, Feb 23, 2010 at 4:47 PM, Robert Kern wrote: > On Tue, Feb 23, 2010 at 13:18, Tom Loredo wrote: >> >> Hi- >> >> I've been testing Python-2.7a3 on Mac OS 10.6.2.  NumPy-1.4.0 will >> not install; it appears something has changed within distutils that >> breaks it: >>  File >> "/Volumes/Sys

Re: [Numpy-discussion] distutils problem with NumPy-1.4 & Py-2.7a3 (Snow Leopard)

On Tue, Feb 23, 2010 at 13:18, Tom Loredo wrote: > > Hi- > > I've been testing Python-2.7a3 on Mac OS 10.6.2.  NumPy-1.4.0 will > not install; it appears something has changed within distutils that > breaks it: >  File > "/Volumes/System/Users/loredo/Downloads/numpy-1.4.0-OSX/numpy/distutils/ccom

Re: [Numpy-discussion] distutils problem with NumPy-1.4 & Py-2.7a3 (Snow Leopard)

On Tue, Feb 23, 2010 at 13:32, Bruce Southey wrote: > On 02/23/2010 01:18 PM, Tom Loredo wrote: >> Hi- >> >> I've been testing Python-2.7a3 on Mac OS 10.6.2.  NumPy-1.4.0 will >> not install; it appears something has changed within distutils that >> breaks it: >> >> $ export MACOSX_DEPLOYMENT_TARG

Re: [Numpy-discussion] distutils problem with NumPy-1.4 & Py-2.7a3 (Snow Leopard)

On 02/23/2010 01:18 PM, Tom Loredo wrote: > Hi- > > I've been testing Python-2.7a3 on Mac OS 10.6.2. NumPy-1.4.0 will > not install; it appears something has changed within distutils that > breaks it: > > $ export MACOSX_DEPLOYMENT_TARGET=10.6 > $ export CFLAGS="-arch x86_64" > $ export FFLAGS="-m

[Numpy-discussion] distutils problem with NumPy-1.4 & Py-2.7a3 (Snow Leopard)

Hi- I've been testing Python-2.7a3 on Mac OS 10.6.2. NumPy-1.4.0 will not install; it appears something has changed within distutils that breaks it: $ export MACOSX_DEPLOYMENT_TARGET=10.6 $ export CFLAGS="-arch x86_64" $ export FFLAGS="-m64" $ export LDFLAGS="-Wall -undefined dynamic_lookup -bu

Re: [Numpy-discussion] Distutils issue? [migrated]

On Fri, Jan 29, 2010 at 18:18, Tom Davis wrote: > [This thread has been migrated from distutils-sig until such a time that it > can be determined if this is a distutils or numpy issue] > A quick recap: Basically, trying to > fix http://projects.scipy.org/numpy/ticket/999 along with some duplicates

[Numpy-discussion] distutils, fcompiler and Mayavi

Hi all, Recentrly I tried to install mayavi-3,3,0, and it failed with a long chain of error messages ended with . . . File "/usr/lib64/python2.6/site-packages/numpy/distutils/command/config_compiler.py", line 66, in finalize_options v = getattr(c,a) File "/usr/lib64/python2.6/distuti

Re: [Numpy-discussion] distutils docstrings; request for review/help

Thanks for "biting this bullet" Ralf. A couple comments (directed more to the "peanut gallery" than to Ralf): obviously, if anyone else besides David C. has the expertise, please help him, Ralf, and indeed all of us, on this; B) I looked at this a little while ago, and reference/distutils.rst just

[Numpy-discussion] distutils docstrings; request for review/help

This request is mainly addressed to David Cournapeau I guess. I wrote docstrings for pretty much all the distutils items not marked "unimportant" in the doc wiki. Pretty much all the info I got from reading the code and comments in it, plus a little bit from reading the distutils.rst file and the

Re: [Numpy-discussion] distutils -- compiling extension twice, two sets of compiler settings

Would two brand new .cpp files abusing of #include do the trick? For example, for '_CCG_dmodule': //file: CCG_dmodule.cxx #define USE_DOUBLE 1 #include "CCG_caller.cpp" #include "ccg_funct.cpp" #include "ccg.cpp" #include "CCG_d_wrap.cxx" Then you can use: ext_ccg_d = Extension('_CCG_dmodule',

[Numpy-discussion] distutils -- compiling extension twice, two sets of compiler settings

Hi, maybe someone here could help me by using distutils: my problem is that I have some C++ files that I need to get compiled twice, first to make a "singleFloat"-module using gcc -DUSE_DOUBLE=0 and then to make the "doubleFloat"-module using gcc -DUSE_DOUBLE=1. Apparently distutils recognises

[Numpy-discussion] distutils chooses wrong arch flags

Could someone with a better knowledge of distutils look over the following SciPy ticket: http://scipy.org/scipy/scipy/ticket/738 Short version: distutils compiles with -march=pentium-m on a machine that can't execute SS2 instructions. -- Nathan Bell [EMAIL PROTECTED] http://graphics.cs.uiuc.edu/

Re: [Numpy-discussion] distutils and inplace build: is numpy supposed to work ?

On Thu, Jul 31, 2008 at 09:18, David Cournapeau <[EMAIL PROTECTED]> wrote: > Hi, > >I wanted to know if numpy was supposed to work when built in place > through the -i option of distutils. The reason why I am asking it that I > would like to support it in numscons, and I cannot make it work whe

Re: [Numpy-discussion] distutils and inplace build: is numpy supposed to work ?

On Thu, Jul 31, 2008 at 8:18 AM, David Cournapeau < [EMAIL PROTECTED]> wrote: > Hi, > >I wanted to know if numpy was supposed to work when built in place > through the -i option of distutils. The reason why I am asking it that I > would like to support it in numscons, and I cannot make it work

[Numpy-discussion] distutils and inplace build: is numpy supposed to work ?

Hi, I wanted to know if numpy was supposed to work when built in place through the -i option of distutils. The reason why I am asking it that I would like to support it in numscons, and I cannot make it work when using distutils. Importing numpy works in the source tree, but most tests fail be

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Fri, Apr 18, 2008 at 1:43 AM, David Cournapeau <[EMAIL PROTECTED]> wrote: > David Cournapeau wrote: > > So it *may* be unrelated to msvc runtime; maybe it just caused a problem > > which has always been there. I will try to see if valgrind says anything > > useful for sparsetools under linux.

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

David Cournapeau wrote: > So it *may* be unrelated to msvc runtime; maybe it just caused a problem > which has always been there. I will try to see if valgrind says anything > useful for sparsetools under linux. > Ok, I think it is unlikely to be caused by msvc runtime problems. Valgrind rep

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

> > > That was in case we publish binaries made with Visual Studio, as David > > asked about this matter. The debugging symbols are indeed different, > > but if it is possible to use Visual Studio, why shouldn't we ? > > > Well, because it is not available freely and is not open source. I am > real

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Robert Kern wrote: > > Quite possibly. Can you run the segfaulting code in a debugger so we > can try to isolate the actual cause? It is possible that we can patch > it up to work with msvcr71. I finally managed to do something, for reference: - I hacked distutils to put -g everywhere (using t

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Matthieu Brucher wrote: > > > 2008/4/18, Robert Kern <[EMAIL PROTECTED] > >: > > On Fri, Apr 18, 2008 at 12:57 AM, Matthieu Brucher > <[EMAIL PROTECTED] > > wrote: > > I can help with packaging at least numpy with Visual Studio 20

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Fri, Apr 18, 2008 at 1:15 AM, Matthieu Brucher <[EMAIL PROTECTED]> wrote: > > > 2008/4/18, Robert Kern <[EMAIL PROTECTED]>: > > On Fri, Apr 18, 2008 at 12:57 AM, Matthieu Brucher > > <[EMAIL PROTECTED]> wrote: > > > I can help with packaging at least numpy with Visual Studio 2003 (well, > I > >

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

2008/4/18, Robert Kern <[EMAIL PROTECTED]>: > > On Fri, Apr 18, 2008 at 12:57 AM, Matthieu Brucher > <[EMAIL PROTECTED]> wrote: > > I can help with packaging at least numpy with Visual Studio 2003 (well, > I > > have to check the EULA if I'm allowed to do that !). For scipy, it is a > > matter of F

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Fri, Apr 18, 2008 at 12:57 AM, Matthieu Brucher <[EMAIL PROTECTED]> wrote: > I can help with packaging at least numpy with Visual Studio 2003 (well, I > have to check the EULA if I'm allowed to do that !). For scipy, it is a > matter of Fortran compiler :| That probably won't work. I believe th

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

2008/4/18, David Cournapeau <[EMAIL PROTECTED]>: > > Robert Kern wrote: > > > > Well, if the official mingw team is committed to not supporting the > > features that we need, then yes, absolutely. This appears to be the > > case. > > > > > Well, this does not seem to work either with gcc 4.3* relea

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

David Cournapeau wrote: > > > Ok, I will have to take a look at how to do that, then, I don't really > have experience with debugger, much less on windows. Will get back one I > understand how this works. > Ok, this is great: when run in gdb, no crash. But when run in cmd.exe, it always cras

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Robert Kern wrote: > On Thu, Apr 17, 2008 at 11:49 PM, David Cournapeau > <[EMAIL PROTECTED]> wrote: > >> Robert Kern wrote: >> > >> > Well, if the official mingw team is committed to not supporting the >> > features that we need, then yes, absolutely. This appears to be the >> > case. >> >>

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Thu, Apr 17, 2008 at 11:49 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Robert Kern wrote: > > > > Well, if the official mingw team is committed to not supporting the > > features that we need, then yes, absolutely. This appears to be the > > case. > > Well, this does not seem to work

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Robert Kern wrote: > > Well, if the official mingw team is committed to not supporting the > features that we need, then yes, absolutely. This appears to be the > case. > Well, this does not seem to work either with gcc 4.3* releases. I got segfaults too. So should we use VS built instead for

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Thu, Apr 17, 2008 at 11:33 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: > Question. How does numpy link against the python library when there is only > a static version present? However distutils tells it to. The information is contained in /usr/local/lib/python2.6/config/Makefile, mostly in

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Question. How does numpy link against the python library when there is only a static version present? I compiled/installed python2.6.2a and the only library it generated was /usr/local/lib/python2.6/config/libpython2.6.a. Furthermore, I didn't see the python library specifically linked by any of th

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Thu, Apr 17, 2008 at 10:56 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Robert Kern wrote: > > > > It seems that Giovanni is getting his gcc from here: > > > > http://www.tdragon.net/recentgcc/ > > > > which also appears to have gfortran binaries, too. > > Would that be acceptable

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Robert Kern wrote: > > It seems that Giovanni is getting his gcc from here: > > http://www.tdragon.net/recentgcc/ > > which also appears to have gfortran binaries, too. > > Would that be acceptable to use for numpy/scipy ? I mean, is it enough if we say to people: you need to install mingw f

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Thu, Apr 17, 2008 at 9:36 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > I also found an unofficial installer for gcc 4.*, which at least claim > to care about python: > > http://www.develer.com/oss/GccWinBinaries > > The problems with the new official (but beta) 4.* builds is the lack of

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

David Cournapeau wrote: > > Distutils uses some tests function to see wether a particular set of > float functions is available (FUNCTIONS_TO_CHECK dict in > numpy/core/setup.py), detects a particular set is not available on mingw > (say 'HAVE_INVERSE_HYPERBOLIC'), and define all of them. The pr

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Robert Kern wrote: > On Thu, Apr 17, 2008 at 9:36 PM, David Cournapeau > <[EMAIL PROTECTED]> wrote: > >> Robert Kern wrote: >> > >> > Ah, this problem again. The build of mingw that you are using were >> > written with msvcrt in mind. For the most part they are compatible >> > with msvcr71,

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Thu, Apr 17, 2008 at 9:36 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Robert Kern wrote: > > > > Ah, this problem again. The build of mingw that you are using were > > written with msvcrt in mind. For the most part they are compatible > > with msvcr71, but there are a few places where

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

Robert Kern wrote: > > Ah, this problem again. The build of mingw that you are using were > written with msvcrt in mind. For the most part they are compatible > with msvcr71, but there are a few places where they reference a table > that is different between the two runtimes, namely iostream in C++

Re: [Numpy-discussion] Distutils: using different linker options for c++ and c code

On Thu, Apr 17, 2008 at 6:34 AM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Hi, > > I cannot seem to make scipy.sparse works on windows with mingw32, > and it seems related to the msvc runtime. I always get segfaults in the > sparsetools module (c++); if I build the module manually to cont

[Numpy-discussion] Distutils: using different linker options for c++ and c code

Hi, I cannot seem to make scipy.sparse works on windows with mingw32, and it seems related to the msvc runtime. I always get segfaults in the sparsetools module (c++); if I build the module manually to control the options precisely and remove the -lmsvc71 from the build command, I cannot r

[Numpy-discussion] [distutils] Best way to add compiler specific library path ?

Hi, While trying to add support for sunperf to numpy.distutils, I came across a simple problem I am not sure how to solve best. I installed the sun compilers for Linux, they are somewhere in my $HOME directory ($HOME/opt/sunstudio/bin). The problem is, when using the fortran compiler, some

Re: [Numpy-discussion] distutils for a Pyrex module

Pierre GM wrote: > On Tuesday 20 March 2007 18:13:09 Robert Kern wrote: >> Pierre GM wrote: >> Hmm. Okay, put the FORTRAN files into a library instead. > > Robert, Pearu, great ! Creating a library did the trick. I eventually come > with that: > > def configuration(parent

Re: [Numpy-discussion] distutils for a Pyrex module

On Tuesday 20 March 2007 18:13:09 Robert Kern wrote: > Pierre GM wrote: > Hmm. Okay, put the FORTRAN files into a library instead. Robert, Pearu, great ! Creating a library did the trick. I eventually come with that: def configuration(parent_package='',top_path=None):

Re: [Numpy-discussion] distutils for a Pyrex module

Pierre GM wrote: > On Tuesday 20 March 2007 17:46:28 Robert Kern wrote: > >> The first file in the sources list should be the one that actually >> implements the module, i.e. the C file generated by Pyrex. FORTRAN files >> specified after the first one won't be processed by f2py. > > Mmh. I had t

Re: [Numpy-discussion] distutils for a Pyrex module

> On Tuesday 20 March 2007 17:46:28 Robert Kern wrote: > >> The first file in the sources list should be the one that actually >> implements the module, i.e. the C file generated by Pyrex. FORTRAN files >> specified after the first one won't be processed by f2py. > > Mmh. I had to get rid of the '*

Re: [Numpy-discussion] distutils for a Pyrex module

On Tuesday 20 March 2007 17:46:28 Robert Kern wrote: > The first file in the sources list should be the one that actually > implements the module, i.e. the C file generated by Pyrex. FORTRAN files > specified after the first one won't be processed by f2py. Mmh. I had to get rid of the '*.pyx' and

Re: [Numpy-discussion] distutils for a Pyrex module

Pierre GM wrote: > All, > I'm trying to write a numpy.distutils setup.py for a pyrex module that > involves both external C and fortran sources, and where the fortran sources > need to be linked w/ blas and lapack. Here's what I have so far: > > ## > def configura

[Numpy-discussion] distutils for a Pyrex module

All, I'm trying to write a numpy.distutils setup.py for a pyrex module that involves both external C and fortran sources, and where the fortran sources need to be linked w/ blas and lapack. Here's what I have so far: ## def configuration(parent_package='',top_path