On Apr 19, 2010, at 03:54, Rainer Müller wrote: > On 2010-04-18 17:22 , Ryan Schmidt wrote: >> >> py26-numpy has a +no_gcc43 variant you can use if you >> want to skip the parts that need a Fortran compiler. > > Probably this has been discussed before and I just couldn't find it in > the archive, but is it really necessary to build the Fortran stuff by > default? > > Upstream recommends to use the Accelerate.framework (or > vecLib.framework) on Mac OS X which is also used with +no_atlas in > py26-numpy. Would the +no_atlas behavior be a more sensible default? > > I know we have our use-our-own-ports policy, but this could be something > where Apple might provide the better library specific to their systems.
You might be right, I haven't looked into it. > Alternatively, I propose we add a new fortran port group which offers > support for possible fortran compilers with variants and auto-selects > the best choice for the current system. This should be based on what is > already installed, so if you already have gfortran-mp-4.4 from gcc44 > this is what would be used instead of installing another copy of gcc. Sounds interesting, but something to pay attention to with such an effort is the other effort that was going on with the science ports, to make all of them use a common compiler (they chose gcc43) because you don't want programs linking with each other if they were compiled for different versions of the gcc libraries. Apparently this is known to cause the universe, or at least those trying to use the software, to explode. I'm concerned that, using this proposed new fortran compiler portgroup, you might at one point in time be building things with one compiler, because that one happens to be installed, and then at some later time you might install a newer compiler (e.g. gcc45) and from then on ports would start compiling with that, leading to gcc library mismatches. Maybe that's not an issue for Fortran like it is for C, but perhaps we consider a similar mechanism for the C compiler, or perhaps the mechanism you develop is not specific to Fortran. _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
