[27018] trunk/base/src/port1.0/portconfigure.tcl

Ryan Schmidt ryandesign at macports.org
Sun Jul 15 16:30:50 PDT 2007


On Jul 15, 2007, at 17:06, source_changes at macosforge.org wrote:

> Revision: 27018
>           http://trac.macosforge.org/projects/macports/changeset/27018
> Author:   mww at macports.org
> Date:     2007-07-15 15:06:34 -0700 (Sun, 15 Jul 2007)
>
> Log Message:
> -----------
> add new commands for selecting compilers:
>     * configure.cc, configure.cxx, .. work just like  
> configure.cflags (no default values)
>     * configure.compiler lets you select a whole compiler  
> collection; this will preset most compiler variables  
> (configure.cc, ..) with their compiler frontend of that compiler  
> version (currently can do gcc-3.3, gcc-4.0, macports-gcc-[0-2])

Interesting! What is the intent?

Initially of course this could simply replace the explicit  
configure.env setting that we're doing in some portfiles.

I hope though that this is also intended to take care of the  
situation where many portfiles explicitly use the system's gcc4 on  
darwin 8, which I don't understand because that should be the default  
anyway. This has bugged me for a long time. Even some of my portfiles  
do it, because they were like that when I took over maintenance of  
them and I don't want to remove those lines until I understand why  
they were added in the first place. It seems like it only guards  
against users who have used gcc_select to select a different default  
compiler. Users should not do that, of course... but now that we have  
this configure.compiler option, we could make "gcc-4.0" the default  
on darwin 8 and "gcc-3.3" the default on darwin 7. Wouldn't that be  
the best idea? Then we could remove the darwin 8 variants from so  
many ports.

The macports-gcc-4.[0-1] options won't work, by the way. The gcc33,  
gcc34, gcc40 and gcc41 ports all still install with the "dp" suffix,  
not the "mp" suffix used by the gcc42 and gcc43 ports. Since we're on  
a DP-to-MP naming switch kick recently we should probably go back and  
fix this for the older GCCs, but we'll have to update a lot of  
portfiles too.

FYI: I corrected the log message (it should have ended "macports- 
gcc-4.[0-3]").

I see you didn't add options for macports-gcc-3.[3-4]. I agree we  
don't need one for gcc33. I see there's only one port that depends on  
gcc33 -- ftidy -- and that only in a variant. I would be inclined to  
remove that variant and the gcc33 port itself. Any objections?

There a couple more ports that depend on gcc34 -- cfitsio (for  
fortran), pgplot (for fortran, on all but darwin 8 i386, where it  
uses gcc42's fortran), ftidy (again in a variant), mercury, algae  
(presumably for fortran), fftw and fftw-single (for fortran), lam  
(for g77), p5-extutils-f77 (for fortran), py-scipy03 (for g77), and  
pdftk (only in a variant). None of those have maintainers, except  
pdftk (me). Perhaps these can all be updated to use gcc42's fortran,  
but it would take some work to test it all. Should we be offering a  
"macports-gcc-3.4" compiler option after all?




More information about the macports-dev mailing list