Commits on Jan 5, 2002
  1. This commit was manufactured by cvs2svn to create tag

    nobody committed Jan 5, 2002
  2. changed import of fastumath as "optional" with a try/except clause. T…

    eric-jones committed Jan 5, 2002
    …his allows people without SciPy, but with Numeric to use blitz.
  3. refined get_version

    pearu committed Jan 5, 2002
  4. refined get_version

    pearu committed Jan 5, 2002
Commits on Jan 4, 2002
  1. added benchmarks

    eric-jones committed Jan 4, 2002
  2. added so that I could specify that all .txt files are inc…

    eric-jones committed Jan 4, 2002
    …luded in the distribution
  3. fixed get_opt for NAG compiler

    pearu committed Jan 4, 2002
  4. fortran extension support

    pearu committed Jan 4, 2002
  5. changed inline() args so that arg_names defaults to an empty list. TH…

    eric-jones committed Jan 4, 2002
    …is allows you to run C code that doesn't need any arguments without supplying any.
  6. fixed catalog test so that it would work if mutliple people were test…

    eric-jones committed Jan 4, 2002
    …ing at same time or if /tmp/test_catalog could not be written.
Commits on Jan 3, 2002
  1. fixed minor bugs

    eric-jones committed Jan 3, 2002
  2. moved test file creation to the temp directory so that it doesn't try…

    eric-jones committed Jan 3, 2002
    … to create files during test in a site-package sub-directory. This caused failues on Unix for testing of installed package.
Commits on Jan 2, 2002
  1. encapsulated all Numeric specific code within a try/except so that mo…

    eric-jones committed Jan 2, 2002
    …st functionality can be used without Numeric installed
  2. Making this a package made installation easier because distutils does…

    eric-jones committed Jan 2, 2002
    …n't allow both py_modules and packages -- not sure it would have worked even if it did
  3. holds searches for fftw libraries on a persons machine. …

    eric-jones committed Jan 2, 2002
    …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. is needed to calculate optimzation flags on linux. It has …

    eric-jones committed Jan 1, 2002
    …much of the same functionality as scipy.proc, but I've included it for now. We'll merge the two later.
  2. Implemented multiple changes provided by Pearu that increased the num…

    eric-jones committed Jan 1, 2002
    …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.
    Something very similar to this already exists in scipy -- its called  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,
    ----- Original Message -----
    From: "Pearu Peterson" <>
    To: "eric" <>
    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 that defines a class for holding
    >    information about CPU. This is used for finding correct optimization
    >    flags for Intel and Gnu compilers. 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 ./ build_flib --fcompiler=Gnu build
    > Could this be useful also in Windows? I guess not.
    > 2) Introduce a new switch for build_flib command:
    >   ./ build_flib --fcompiler=Gnu --fcompiler_exec=g77-3.0 build
    Doing 2 is fine with me -- and you've already done it I see. :)
  3. changed to using fortran class instead of instance for setting fortra…

    eric-jones committed Jan 1, 2002
    …n compiler. This was needed after Pearu's changes.