On Dec 5, 2007 1:14 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> David Cournapeau wrote:
>
> > So to go back to your problem: if I understand correctly, what is needed
> > is to update the scons tools. Since those are kept at one place, I think
> > it would be safe to update them independently. But
On Dec 5, 2007 3:11 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
> I was only reading code; I haven't tested building Fortran extensions, yet.
> However, using a generic link tool would be the wrong thing to do for most
> Fortran extensions, I think. Where does it get the correct Fortran runtime
>
David Cournapeau wrote:
> On Dec 5, 2007 3:07 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>>
>> I don't see how that's relevant to the problem I raised. Supporting Fortran
>> in
>> the standard library would make the problem even worse. distutils is
>> certainly
>> not broken because it doesn't su
On Dec 5, 2007 3:07 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
>
> I don't see how that's relevant to the problem I raised. Supporting Fortran in
> the standard library would make the problem even worse. distutils is certainly
> not broken because it doesn't support Fortran.
>
Fortran support is
David Cournapeau wrote:
> On Dec 5, 2007 1:19 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>> David Cournapeau wrote:
>>> Robert Kern wrote:
David Cournapeau wrote:
> - I have not yet tweaked fortran compiler configurations for
> optimizations except for gnu compilers
Can y
David Cournapeau wrote:
> On Dec 5, 2007 1:14 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>> This, too, is a workaround for the less-than-desirable situation of having
>> numpy's sizable build infrastructure bundled with the numpy package itself.
>> If
>> this stuff were an entirely separate packa
On Dec 5, 2007 1:14 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> David Cournapeau wrote:
>
> > So to go back to your problem: if I understand correctly, what is needed
> > is to update the scons tools. Since those are kept at one place, I think
> > it would be safe to update them independently. But
On Dec 5, 2007 1:19 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> David Cournapeau wrote:
> > Robert Kern wrote:
> >> David Cournapeau wrote:
> >>
> >>> - I have not yet tweaked fortran compiler configurations for
> >>> optimizations except for gnu compilers
> >> Can you give us a brief overview
David Cournapeau wrote:
> Robert Kern wrote:
>> David Cournapeau wrote:
>>
>>> - I have not yet tweaked fortran compiler configurations for
>>> optimizations except for gnu compilers
>> Can you give us a brief overview about how to do this? For example, the Intel
>> Fortran compiler's SHLINKFL
David Cournapeau wrote:
> So to go back to your problem: if I understand correctly, what is needed
> is to update the scons tools. Since those are kept at one place, I think
> it would be safe to update them independently. But I don't understand
> exactly how this could be installed in the sour
Robert Kern wrote:
> David Cournapeau wrote:
>
>> - I have not yet tweaked fortran compiler configurations for
>> optimizations except for gnu compilers
>
> Can you give us a brief overview about how to do this? For example, the Intel
> Fortran compiler's SHLINKFLAGS in scons-local/.../SCons/T
Robert Kern wrote:
>
>
> Tweaking should be the province of the developer and the desperate. We have to
> be able to tweak, but we should spend more time on preventing the need for
> tweaking.
>
Yes, I can only agree 100 % with you. This is maybe *the* reason why I
started this whole thing. Di
Robert Kern wrote:
> David Cournapeau wrote:
>> Some of the most interesting things I can think of which work with scons:
>> - you can control fortran and C flags from the command line: CFLAGS
>> and FFLAGS won't override necessary flags, only optimization flags, so
>> you can easily play wit
David Cournapeau wrote:
> - I have not yet tweaked fortran compiler configurations for
> optimizations except for gnu compilers
Can you give us a brief overview about how to do this? For example, the Intel
Fortran compiler's SHLINKFLAGS in scons-local/.../SCons/Tool/ifort.py are
incorrect fo
Fernando Perez wrote:
> On Dec 4, 2007 1:24 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>> Fernando Perez wrote:
>
>>> Is this something that really needs to be a code package? Why can't
>>> this knowledge (or at least the easily overridable part of it) be
>>> packaged in one or more .conf/.ini pl
On Dec 4, 2007 1:24 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
> Fernando Perez wrote:
> > Is this something that really needs to be a code package? Why can't
> > this knowledge (or at least the easily overridable part of it) be
> > packaged in one or more .conf/.ini plaintext files? In that w
Fernando Perez wrote:
> On Dec 4, 2007 12:27 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
>> user-friendly. Another option is to have our Fortran compiler
>> "knowledge-base"
>> separable from the rest of the package. scons could try to import them from,
>> say, numpy_fcompilers first and then lo
On Dec 4, 2007 12:27 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> user-friendly. Another option is to have our Fortran compiler "knowledge-base"
> separable from the rest of the package. scons could try to import them from,
> say, numpy_fcompilers first and then look inside numpy.distutils if
> nu
David Cournapeau wrote:
> Some of the most interesting things I can think of which work with scons:
> - you can control fortran and C flags from the command line: CFLAGS
> and FFLAGS won't override necessary flags, only optimization flags, so
> you can easily play with warning, optimization f
On Dec 4, 2007 11:23 PM, Matthieu Brucher <[EMAIL PROTECTED]> wrote:
>
> > This is great stuff by the way, consider me a scons convert.
> >
>
> I'm already convinced for some time. Now, we just need an egg Builder :|
No we don't, since we are still using distutils: scons really just
handles compile
On Dec 4, 2007 11:20 PM, David Huard <[EMAIL PROTECTED]> wrote:
> David,
>
> I tried building the scons numpy and scipy. Numpy apparently built fine
> since all tests pass. For scipy, I am having problem during the build.
> Something seems to be wrong with libdfftpack.a
>
G, this is because of
>
> This is great stuff by the way, consider me a scons convert.
>
I'm already convinced for some time. Now, we just need an egg Builder :|
Matthieu
--
French PhD student
Website : http://miles.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : htt
David,
I tried building the scons numpy and scipy. Numpy apparently built fine
since all tests pass. For scipy, I am having problem during the build.
Something seems to be wrong with libdfftpack.a
I'm attaching the terminal output.
Ubuntu 7.10, Xeon 64.
HTH,
David
This is great stuff by the w
Hi,
I've just reached a first usable scipy.scons branch, so that scipy
can be built entirely with scons (assuming you build numpy with scons
too). You can get it from
http://svn.scipy.org/svn/scipy/branches/scipy.scons. To build it, you
just need to use numpy.scons branch instead of the tr
24 matches
Mail list logo
