On Jul 15, 2007, at 17:06, [EMAIL PROTECTED] wrote:
Revision: 27018
http://trac.macosforge.org/projects/macports/changeset/27018
Author: [EMAIL PROTECTED]
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?
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
