Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Jan 5, 2002
  1. This commit was manufactured by cvs2svn to create tag

    nobody authored
    'release_0_2_0'.
  2. @eric-jones

    changed import of fastumath as "optional" with a try/except clause. T…

    eric-jones authored
    …his allows people without SciPy, but with Numeric to use blitz.
  3. @pearu

    refined get_version

    pearu authored
  4. @pearu

    refined get_version

    pearu authored
Commits on Jan 4, 2002
  1. @eric-jones
  2. @eric-jones
  3. @pearu
  4. @eric-jones
  5. @eric-jones

    added benchmarks

    eric-jones authored
  6. @eric-jones
  7. @eric-jones
  8. @eric-jones
  9. @eric-jones
  10. @eric-jones
  11. @pearu

    fixed get_opt for NAG compiler

    pearu authored
  12. @pearu

    fortran extension support

    pearu authored
  13. @eric-jones

    changed inline() args so that arg_names defaults to an empty list. TH…

    eric-jones authored
    …is allows you to run C code that doesn't need any arguments without supplying any.
  14. @eric-jones

    fixed catalog test so that it would work if mutliple people were test…

    eric-jones authored
    …ing at same time or if /tmp/test_catalog could not be written.
Commits on Jan 3, 2002
  1. @eric-jones

    fixed minor bugs

    eric-jones authored
  2. @eric-jones
  3. @eric-jones

    moved test file creation to the temp directory so that it doesn't try…

    eric-jones authored
    … to create files during test in a site-package sub-directory. This caused failues on Unix for testing of installed package.
  4. @eric-jones
  5. @eric-jones
  6. @eric-jones
  7. @eric-jones
  8. @eric-jones

    renaming compiler to weave

    eric-jones authored
Commits on Jan 2, 2002
  1. @eric-jones

    encapsulated all Numeric specific code within a try/except so that mo…

    eric-jones authored
    …st functionality can be used without Numeric installed
  2. @eric-jones

    Making this a package made installation easier because distutils does…

    eric-jones authored
    …n't allow both py_modules and packages -- not sure it would have worked even if it did
  3. @eric-jones
  4. @eric-jones
  5. @eric-jones

    fftw_info.py holds searches for fftw libraries on a persons machine. …

    eric-jones authored
    …It is made separate from the fftw library because it may be needed by other libraries later on. Also, it could become useful to other projects trying to find fftw on a mchine. Its very simple right now.
Commits on Jan 1, 2002
  1. @eric-jones
  2. @eric-jones

    cpuinfo.py is needed to calculate optimzation flags on linux. It has …

    eric-jones authored
    …much of the same functionality as scipy.proc, but I've included it for now. We'll merge the two later.
  3. @eric-jones

    Implemented multiple changes provided by Pearu that increased the num…

    eric-jones authored
    …ber of compilers supported, added some optimization flags, and generally cleaned things up. I made changes needed to get things rolling for scipy on win32 again. I've included an email exchange discussing changes below:
    
    I changes are checked into CVS.
    
    1. is_available()
    In is_available(), I'm not sure whether any compilers will return an empty version.  I don't think any of them do right now -- but I'm not sure about Sun.  For now, lets use your implementation and deal with it later if it turns out to be a problem.
    
    2. sun compile switches
    class sun_fortran_compiler(fortran_compiler_base):
    
        vendor = 'Sun'
        ver_match =  r'f77: (?P<version>[^\s*,]*)'
    
        def __init__(self, fc = None, f90c = None):
            ...
            self.f90_switches = ' -fixed ' # ??? why fixed?
    
    
    I think the fixed is left over from some compiler specific flags I needed in a project at Duke where all of our code was in fixed format.  It probably shouldn't be here.  However, if it isn't, we need a way of specifying the compiler options.  In distutils.extension, there is a
    
        self.extra_compile_args = extra_compile_args or []
    
    argument.  We need an extra_fcompile_args or something like that.  I think distutils just appends the extra arguments to the end of the compile command.  This is unlikely to work with some Fortran compilers though.  I know the Absoft compiler isn't very sophisticated about handling command line arguments, and any extra args probably need to be placed before the source file in the command.
    
    3. cpu_info.py
    Something very similar to this already exists in scipy -- its called proc.py.  I'll look through it and see how to merge the stuff you added into the module.  This stuff is very OS specific and only works on Linux (and maybe BSD).  I wish proc worked on more machine types.
    
    *Well, for now I'm gonna keep the two separate modules.  We'll merge this stuff into proc in the future.
    
    4. optimization flags
    I've moved this to a get_opt() function.
    
    Also, we should have a flag to turn *on* machine specific optimization instead of making it the
    default.  If people build a binary distibution, it'll only work on specific architectures which can lead to trouble.  This shouldn't be the default behavior.
    
    For now, get_opt() still calls the arch dependent settings by default for the gnu and intel compilers.
    
    5. get_linker_so()
    This won't work on windows with mingw32.  The linker is a very strange thing there, and the -shared flag doesn't work.  I've had to add a little code back into the gnu_fortran class and
    do a test for win32.  I don't think seeting the libraries and library_dir hurts on linux.  Does it?
    
    6. is_available -> get_version
    This is just a better name for it.  is_available is still available... :)  It just calls get_version now.
    
    7. ***  Some vendors provide different compilers for F77 and F90
            compilations. Currently, checking the availability of these
            compilers is based on only checking the availability of the
            corresponding F77 compiler. If it exists, then F90 is assumed
            to exist also.
    
    This is a problem.  Worse than having different ones, gnu fortran doesn't even support f90.  We may want to split this stuff into separate classes.  I'd like to get more feedback from users running into problems on this one.
    
    see ya,
    eric
    
    ----- Original Message -----
    From: "Pearu Peterson" <pearu@cens.ioc.ee>
    To: "eric" <eric@enthought.com>
    Sent: Monday, December 31, 2001 11:38 AM
    Subject: build_flib patch
    
    
    >
    > Hi Eric,
    >
    > Please find attached my changes to build_flib:
    >
    > *  Added NAGWare, VAST/f90 compilers support.
    > *  Refined Intel compiler support.
    > *  Added more aggressive optimization for Intel and Gnu compilers.
    > *  Added options --fcompiler-exec and --f90compiler-exec.
    > *  The later required some rewrote for compiler classes handling:
    >      Eg. the list all_compilers holds now compiler classes, not their
    >      instances. As a side effect, the handling is more efficient now.
    >      Etc.
    > *  Introduced a new file cpuinfo.py that defines a class for holding
    >    information about CPU. This is used for finding correct optimization
    >    flags for Intel and Gnu compilers. build_flib.py imports it.
    > *  get_f*_files functions recognize other Fortran file extensions as well.
    > *  Docs about bugs.
    > *  Cleaned up the code a bit.
    >
    > Happy New Year!
    > Pearu
    >
    
    -------
    
    > > One thing I noticed.  I think the intel compilers should come before the gnu
    > > compiler in the list so that they are used by default if both are installed.
    > > What do you think?
    >
    > I think the order should not matter. Users should use --fcompiler flag to
    > specify desired compiler. I have fixed this in my local source of
    > scipy_distutils, I'll send it later with other changes.
    
    If we move it up in the list, the default behavior will grab the "better" (or at least the commercial) compiler installed on the platform.  I think this is more desirable.  People can still specifiy the gnu compiler with a flag if they want to.  If they have many compilers installed, the flag is the only way to do it that I see.
    
    >
    > But there is one thing that should be addressed as well. And that is if
    > one wants to specify the path to the desired compiler (eg for
    > testing/using different compilers or different versions of the same
    > compiler). For example, on debian there are two F77 compilers, g77 (that
    > is 2.95.2) and g77-3.0. Both are Gnu, and the same class instance should
    > be used. So, to solve this, I can think of many solutions:
    >
    > 1) Get the compiler path from FC environment variable, so that one can run
    >
    >   FC=g77-3.0 ./setup.py build_flib --fcompiler=Gnu build
    >
    > Could this be useful also in Windows? I guess not.
    >
    > 2) Introduce a new switch for build_flib command:
    >
    >   ./setup.py build_flib --fcompiler=Gnu --fcompiler_exec=g77-3.0 build
    >
    
    Doing 2 is fine with me -- and you've already done it I see. :)
    
    eric
  4. @eric-jones

    changed to using fortran class instead of instance for setting fortra…

    eric-jones authored
    …n compiler. This was needed after Pearu's changes.
Something went wrong with that request. Please try again.