…his allows people without SciPy, but with Numeric to use blitz.
…luded in the distribution
…is allows you to run C code that doesn't need any arguments without supplying any.
…ing at same time or if /tmp/test_catalog could not be written.
… to create files during test in a site-package sub-directory. This caused failues on Unix for testing of installed package.
…st functionality can be used without Numeric installed
…n't allow both py_modules and packages -- not sure it would have worked even if it did
…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.
…much of the same functionality as scipy.proc, but I've included it for now. We'll merge the two later.
…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" <firstname.lastname@example.org> To: "eric" <email@example.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
…n compiler. This was needed after Pearu's changes.