We're tentatively considering making having a fortran compiler a prerequisite for building SAGE from source. See below for the discussion, if you're interested. Basically, this will make it much easier for SAGE to be useful to a vast range of engineers that do numerical computation.
---------- Forwarded message ---------- From: Brian Granger <[EMAIL PROTECTED]> Date: May 24, 2007 10:02 AM Subject: Re: fortran To: William Stein <[EMAIL PROTECTED]> Cc: Joshua Kantor <[EMAIL PROTECTED]> > Sorry I haven't responded to your spkg proposals on sage-devel yesterday. > Some > of them make me slightly uncomfortable, so I want to mull them over > before saying > anything hasty. No problem. I am very open to other ways of handling the ongoing development of the spkgs and the corresponding scripts/makefiles. I mainly just want a better way of staying synchronized with SAGE and of being able to develop all that in a repository for source control and backup purposes. > Regarding Fortran, it seems more and more that Fortran should just be > a requirement > for building SAGE from source. On Linux getting fortran is trivial. > On OS X it used > to be hard, but my impression is now it's pretty easy. SAGE isn't > supporting cygwin > anymore (we're doing MS windows via VMware). > > So, what are your thoughts about Fortran, it being a requirement for > building SAGE, > and the ease of installing it on various platforms? Josh, what do you think? I think having fortran as a prereq is not a bad idea. Currently, we have fortran as a requirement for some of the packages we are distributing. Here is how we are handling it (not sure this is the best way, but it has worked Ok thus far). The main packages that need fortran are: * numpy - fortran is an optional req if you want to use f2py * scipy - fortran is required and you must use the same fortran used for numpy * enthought tools - need fortran through its dependence on scipy * hdf5/openmpi - can optionally build with fortran bindings. We don't do this currently, but we could start doing this. * Anything new spkgs that would want to use fortran directly or depend on one of the above. The way we handle the fortran requirement currently is that is use must set the NUMPY_FCOMPILER enviroment variable to tell which fortran compiler to use. Numpy and scipy have a convention whereby each fortran compiler is specified by a simply string: For example, gfortran is the string gnu95. Thus, the following would cause gfortran to be used: export NUMPY_FCOMPILER=gnu95 This approach assumes that the corresponding fortran compiler is installed in a standard location (such as /usr/local). The only problem with this approach to specifying the fortran compiler is that it only works for numpy/scipy. For other packages like hdf5/openmpi, we would need a different way of specifying which fortran compiler should be used. As far as how users would get the fortran compiler, here is my recommendation. While, I am not a heavy fortran user, fortran is heavily used at my company and these conclusions are based upon lots of discussions with folks about this questions. In general, people tend to fall in one of two categories: 1) don't every use fortran themselves and thus don't really care what fortran compiler is used. For these folks, it look as though gfortran is the best option. It is easily available for both OS X (on the HPC for OS X website: http://hpc.sourceforge.net/) and for linux. Numpy/scipy/hdf5/openmpi find these compilers without problems. For most people, I think this should be the recommended route. On linux, using g77 is also an option, but g77 is not recomended on Macs. 2) People who use fortran and really want to use a specific fortran compiler, like the intel fortran compiler. We should also support this approach. Thankfully it is easy to get scipy/numpy/hdf5/openmpi to work with these compilers. To go this route, we should probably do the following: 1) Require the user to specify an environment variable that somehow points to the desired fortran compiler. 2) Add checks in prereq to make sure that compiler is actually there and working 3) Have numpy/scipy and other packages use the environment variable to setup the compilers proper usage for that package. Thoughts? Feedback? Brian > -- > William Stein > Associate Professor of Mathematics > University of Washington > http://www.williamstein.org > -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
