Changes between Version 87 and Version 88 of PortfileRecipes

Timestamp:

Jun 5, 2015, 4:07:32 PM (9 years ago)

Author:

dstrubbe (David Strubbe)

Comment:

--

PortfileRecipes

@@ -419 +419 @@
 == Providing compiler variants == #gcc
 
-'''This recipe is not recommended.  Please do not use it in new ports'''
+'''This recipe is not recommended.  Please do not use it in new ports. Use the compilers PortGroup instead.'''
 
 Use of the C++ and ObjC compilers provided by macports-gcc-X.Y compiler options (and by extension, dragonegg compiler options) is strongly discouraged because it will lead to different C++ and ObjC runtimes being used by different ports (which can make such ports incompatible with each other).  The general rule of thumb is that if the C++ or ObjC usage is wholly contained within the port, it is safe to use the gcc compilers.  If the port uses C++ or ObjC APIs provided by the host or other ports, then you must use an Apple provided compiler or one of the macports-clang compilers.  Similarly, if the port is providing ObjC or C++ APIs to other ports, then it must use an Apple provided compiler or one of the macports-clang ports.  See the next section below for instructions on how to choose just the fortran compiler based on gcc variants.
@@ -494 +494 @@
 
 == Selecting a Fortran Compiler == #fortran
+
+'''This recipe is not recommended.  Please do not use it in new ports. Use the compilers PortGroup instead.'''
 
 The default Apple-provided compilers (and the clang compilers from MacPorts) do not support as many languages as the gcc ports.  The Portfile recipe below will allow you to compile fortran code while still using the default compiler for C, ObjC, C++, and ObjC++ code.  If your port uses gcj, the same process can be used to select a gcj compiler.