summaryrefslogtreecommitdiff
path: root/devel/boost-libs/files/patch-clang-as
diff options
context:
space:
mode:
authorGerald Pfeifer <gerald@FreeBSD.org>2017-05-02 05:40:53 +0000
committerGerald Pfeifer <gerald@FreeBSD.org>2017-05-02 05:40:53 +0000
commitd20f7422507bf1d93720a8588f8770f963875a60 (patch)
tree08738e33add432f30d9977da48e6d32eaf62719e /devel/boost-libs/files/patch-clang-as
parentUpdate math/gsl to 2.3 (diff)
As of today, USE_GCC=yes (and USE_GCC=any in most circumstances)
and consequently many of the USES=compiler flavors use the canonical version of GCC as defined in Mk/bsd.default-versions.mk as well as the lang/gcc port With the "new" setup starting with GCC 5 where I have introduced lang/gcc5-devel for regular snapshots and lang/gcc5 for releases, and similarly for GCC 6 and onward, we can now leverage lang/gcc5 (and later) for most of the role that lang/gcc used to play -- and indeed as of today lang/gcc and lang/gcc5 are nearly identical short of symlinks for gcc, g++, and gfortran binaries that the former provides. So now use lang/gcc5 instead of lang/gcc whenever requested via the USE_GCC framework directly or indirectly. This is similar to how the python ports work, for example, and it allows simplifications in Mk/bsd.gcc.mk and Mk/Uses/fortran.mk and dropping LANG_GCC_IS from Mk/bsd.default-versions.mk. As a next step lang/gcc is going to become a "hull" essentially only providing those symlinks and requiring lang/gcc5 (or whatever has been set as default in Mk/bsd.default-versions.mk).
Notes
Notes: svn path=/head/; revision=439929
Diffstat (limited to 'devel/boost-libs/files/patch-clang-as')
0 files changed, 0 insertions, 0 deletions