d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
bf15fc88e9
freebsd-nq/share/mk/bsd.compiler.mk

59 lines
1.8 KiB
Makefile
Raw Normal View History

Introduce a new make variable COMPILER_TYPE that specifies what type of compiler is being used (currently clang or gcc). COMPILER_TYPE is set in the new bsd.compiler.mk file based on the value of the CC variable or, should it prove informative, by running ${CC} --version and examining the output. To avoid negative performance impacts in the default case and correct value for COMPILER_TYPE type is determined and passed in the environment of submake instances while building world. Replace adhoc attempts at determining the compiler type by examining CC or MK_CLANG_IS_CC with checks of COMPILER_TYPE. This eliminates bootstrapping complications when first setting WITH_CLANG_IS_CC. Sponsored by: DARPA, AFRL Reviewed by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>, imp, linimon (with some modifications post review) MFC after: 2 weeks
2012-09-13 16:00:46 +00:00
# $FreeBSD$
Support, to the extent we generate proper command lines, compiling with clang 3.3. Useful for test building -current on a -stable system in individual directories. Potentially useful if we ever want to support, say, gcc 4.8 or 4.9's new warnings when building with an external toolchain (but such support not yet committed). Document the bsd.compiler.mk interface.
2014-05-10 16:37:44 +00:00
# Setup variables for the compiler
#
Fix typos in comments and wrap to <80 columns MFC after: 3 days
2014-12-06 03:12:57 +00:00
# COMPILER_TYPE is the major type of compiler. Currently gcc and clang support
# automatic detection. Other compiler types can be shoe-horned in, but require
# explicit setting of the compiler type. The compiler type can also be set
# explicitly if, say, you install gcc as clang...
Support, to the extent we generate proper command lines, compiling with clang 3.3. Useful for test building -current on a -stable system in individual directories. Potentially useful if we ever want to support, say, gcc 4.8 or 4.9's new warnings when building with an external toolchain (but such support not yet committed). Document the bsd.compiler.mk interface.
2014-05-10 16:37:44 +00:00
#
Fix typos in comments and wrap to <80 columns MFC after: 3 days
2014-12-06 03:12:57 +00:00
# COMPILER_VERSION is a numeric constant equal to:
# major * 10000 + minor * 100 + tiny
# It too can be overriden on the command line. When testing it, be sure to
# make sure that you are limiting the test to a specific compiler. Testing
# against 30300 for gcc likely isn't what you wanted (since versions of gcc
# prior to 4.2 likely have no prayer of working).
Support, to the extent we generate proper command lines, compiling with clang 3.3. Useful for test building -current on a -stable system in individual directories. Potentially useful if we ever want to support, say, gcc 4.8 or 4.9's new warnings when building with an external toolchain (but such support not yet committed). Document the bsd.compiler.mk interface.
2014-05-10 16:37:44 +00:00
#
Fix typos in comments and wrap to <80 columns MFC after: 3 days
2014-12-06 03:12:57 +00:00
# COMPILER_FEATURES will contain one or more of the following, based on
# compiler support for that feature:
#
# - c++11 : supports full (or nearly full) C++11 programming environment.
Support, to the extent we generate proper command lines, compiling with clang 3.3. Useful for test building -current on a -stable system in individual directories. Potentially useful if we ever want to support, say, gcc 4.8 or 4.9's new warnings when building with an external toolchain (but such support not yet committed). Document the bsd.compiler.mk interface.
2014-05-10 16:37:44 +00:00
#
# This file may be included multiple times, but only has effect the first time.
#
bsd.compiler.mk was implicitly included by bsd.own.mk in historical versions. With its movement to src.opts.mk, bsd.prog.mk was testing COMPILER_TYPE without including the bsd.compiler.mk anymore. In the source tree, this caused no problems, for reasons that aren't clear, but does cause problems outside of the source tree. Allow bsd.compiler.mk to be included multiple times safely, and always include bsd.compiler.mk at the top of bsd.prog.mk. Resist the urge to put it in bsd.init.mk, since that would reintroduce the implicit include.
2014-05-07 18:15:02 +00:00
.if !target(__<bsd.compiler.mk>__)
__<bsd.compiler.mk>__:
The previous commit should have been a logical or not a logical "and" Pointyhat to: me
2014-12-08 03:32:26 +00:00
.if !defined(COMPILER_TYPE) || !defined(COMPILER_VERSION)
Allow CC to not actually exist. During the ports INDEX run, all the Makefiles are evaluated without building things. In a normal build, the prerequisites would be built, and CC would be an actual thing. In an INDEX build, though, they don't exists. Redirect stderr to get rid of annoying messages, and assume that the compiler version is 0 if the actual compiler can't tell us. Do this in preference to guessing based on numbers because gcc410 might be 4.10, or 4.1.0 and without carefully crafted special knowledge we differentiate between them easily (also ming-gcc has no clues at all). Elsewhere, don't trust the compiler version if it is 0.
2014-05-23 14:34:22 +00:00
_v!= ${CC} --version 2>/dev/null || echo 0.0.0
Introduce a new make variable COMPILER_TYPE that specifies what type of compiler is being used (currently clang or gcc). COMPILER_TYPE is set in the new bsd.compiler.mk file based on the value of the CC variable or, should it prove informative, by running ${CC} --version and examining the output. To avoid negative performance impacts in the default case and correct value for COMPILER_TYPE type is determined and passed in the environment of submake instances while building world. Replace adhoc attempts at determining the compiler type by examining CC or MK_CLANG_IS_CC with checks of COMPILER_TYPE. This eliminates bootstrapping complications when first setting WITH_CLANG_IS_CC. Sponsored by: DARPA, AFRL Reviewed by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>, imp, linimon (with some modifications post review) MFC after: 2 weeks
2012-09-13 16:00:46 +00:00
.if !defined(COMPILER_TYPE)
Allow CC to not actually exist. During the ports INDEX run, all the Makefiles are evaluated without building things. In a normal build, the prerequisites would be built, and CC would be an actual thing. In an INDEX build, though, they don't exists. Redirect stderr to get rid of annoying messages, and assume that the compiler version is 0 if the actual compiler can't tell us. Do this in preference to guessing based on numbers because gcc410 might be 4.10, or 4.1.0 and without carefully crafted special knowledge we differentiate between them easily (also ming-gcc has no clues at all). Elsewhere, don't trust the compiler version if it is 0.
2014-05-23 14:34:22 +00:00
. if ${CC:T:M*gcc*}
Introduce a new make variable COMPILER_TYPE that specifies what type of compiler is being used (currently clang or gcc). COMPILER_TYPE is set in the new bsd.compiler.mk file based on the value of the CC variable or, should it prove informative, by running ${CC} --version and examining the output. To avoid negative performance impacts in the default case and correct value for COMPILER_TYPE type is determined and passed in the environment of submake instances while building world. Replace adhoc attempts at determining the compiler type by examining CC or MK_CLANG_IS_CC with checks of COMPILER_TYPE. This eliminates bootstrapping complications when first setting WITH_CLANG_IS_CC. Sponsored by: DARPA, AFRL Reviewed by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>, imp, linimon (with some modifications post review) MFC after: 2 weeks
2012-09-13 16:00:46 +00:00
COMPILER_TYPE:= gcc
Allow CC to not actually exist. During the ports INDEX run, all the Makefiles are evaluated without building things. In a normal build, the prerequisites would be built, and CC would be an actual thing. In an INDEX build, though, they don't exists. Redirect stderr to get rid of annoying messages, and assume that the compiler version is 0 if the actual compiler can't tell us. Do this in preference to guessing based on numbers because gcc410 might be 4.10, or 4.1.0 and without carefully crafted special knowledge we differentiate between them easily (also ming-gcc has no clues at all). Elsewhere, don't trust the compiler version if it is 0.
2014-05-23 14:34:22 +00:00
. elif ${CC:T:M*clang*}
Introduce a new make variable COMPILER_TYPE that specifies what type of compiler is being used (currently clang or gcc). COMPILER_TYPE is set in the new bsd.compiler.mk file based on the value of the CC variable or, should it prove informative, by running ${CC} --version and examining the output. To avoid negative performance impacts in the default case and correct value for COMPILER_TYPE type is determined and passed in the environment of submake instances while building world. Replace adhoc attempts at determining the compiler type by examining CC or MK_CLANG_IS_CC with checks of COMPILER_TYPE. This eliminates bootstrapping complications when first setting WITH_CLANG_IS_CC. Sponsored by: DARPA, AFRL Reviewed by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>, imp, linimon (with some modifications post review) MFC after: 2 weeks
2012-09-13 16:00:46 +00:00
COMPILER_TYPE:= clang
Support, to the extent we generate proper command lines, compiling with clang 3.3. Useful for test building -current on a -stable system in individual directories. Potentially useful if we ever want to support, say, gcc 4.8 or 4.9's new warnings when building with an external toolchain (but such support not yet committed). Document the bsd.compiler.mk interface.
2014-05-10 16:37:44 +00:00
. elif ${_v:Mgcc}
Introduce a new make variable COMPILER_TYPE that specifies what type of compiler is being used (currently clang or gcc). COMPILER_TYPE is set in the new bsd.compiler.mk file based on the value of the CC variable or, should it prove informative, by running ${CC} --version and examining the output. To avoid negative performance impacts in the default case and correct value for COMPILER_TYPE type is determined and passed in the environment of submake instances while building world. Replace adhoc attempts at determining the compiler type by examining CC or MK_CLANG_IS_CC with checks of COMPILER_TYPE. This eliminates bootstrapping complications when first setting WITH_CLANG_IS_CC. Sponsored by: DARPA, AFRL Reviewed by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>, imp, linimon (with some modifications post review) MFC after: 2 weeks
2012-09-13 16:00:46 +00:00
COMPILER_TYPE:= gcc
Support, to the extent we generate proper command lines, compiling with clang 3.3. Useful for test building -current on a -stable system in individual directories. Potentially useful if we ever want to support, say, gcc 4.8 or 4.9's new warnings when building with an external toolchain (but such support not yet committed). Document the bsd.compiler.mk interface.
2014-05-10 16:37:44 +00:00
. elif ${_v:M\(GCC\)}
Introduce a new make variable COMPILER_TYPE that specifies what type of compiler is being used (currently clang or gcc). COMPILER_TYPE is set in the new bsd.compiler.mk file based on the value of the CC variable or, should it prove informative, by running ${CC} --version and examining the output. To avoid negative performance impacts in the default case and correct value for COMPILER_TYPE type is determined and passed in the environment of submake instances while building world. Replace adhoc attempts at determining the compiler type by examining CC or MK_CLANG_IS_CC with checks of COMPILER_TYPE. This eliminates bootstrapping complications when first setting WITH_CLANG_IS_CC. Sponsored by: DARPA, AFRL Reviewed by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>, imp, linimon (with some modifications post review) MFC after: 2 weeks
2012-09-13 16:00:46 +00:00
COMPILER_TYPE:= gcc
Support, to the extent we generate proper command lines, compiling with clang 3.3. Useful for test building -current on a -stable system in individual directories. Potentially useful if we ever want to support, say, gcc 4.8 or 4.9's new warnings when building with an external toolchain (but such support not yet committed). Document the bsd.compiler.mk interface.
2014-05-10 16:37:44 +00:00
. elif ${_v:Mclang}
Introduce a new make variable COMPILER_TYPE that specifies what type of compiler is being used (currently clang or gcc). COMPILER_TYPE is set in the new bsd.compiler.mk file based on the value of the CC variable or, should it prove informative, by running ${CC} --version and examining the output. To avoid negative performance impacts in the default case and correct value for COMPILER_TYPE type is determined and passed in the environment of submake instances while building world. Replace adhoc attempts at determining the compiler type by examining CC or MK_CLANG_IS_CC with checks of COMPILER_TYPE. This eliminates bootstrapping complications when first setting WITH_CLANG_IS_CC. Sponsored by: DARPA, AFRL Reviewed by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>, imp, linimon (with some modifications post review) MFC after: 2 weeks
2012-09-13 16:00:46 +00:00
COMPILER_TYPE:= clang
Support, to the extent we generate proper command lines, compiling with clang 3.3. Useful for test building -current on a -stable system in individual directories. Potentially useful if we ever want to support, say, gcc 4.8 or 4.9's new warnings when building with an external toolchain (but such support not yet committed). Document the bsd.compiler.mk interface.
2014-05-10 16:37:44 +00:00
. else
Provide slightly more helpful feedback when we can't figure out what compiler the user is using. PR: misc/173914
2013-03-01 03:25:43 +00:00
.error Unable to determine compiler type for ${CC}. Consider setting COMPILER_TYPE.
Introduce a new make variable COMPILER_TYPE that specifies what type of compiler is being used (currently clang or gcc). COMPILER_TYPE is set in the new bsd.compiler.mk file based on the value of the CC variable or, should it prove informative, by running ${CC} --version and examining the output. To avoid negative performance impacts in the default case and correct value for COMPILER_TYPE type is determined and passed in the environment of submake instances while building world. Replace adhoc attempts at determining the compiler type by examining CC or MK_CLANG_IS_CC with checks of COMPILER_TYPE. This eliminates bootstrapping complications when first setting WITH_CLANG_IS_CC. Sponsored by: DARPA, AFRL Reviewed by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>, imp, linimon (with some modifications post review) MFC after: 2 weeks
2012-09-13 16:00:46 +00:00
. endif
.endif
Support, to the extent we generate proper command lines, compiling with clang 3.3. Useful for test building -current on a -stable system in individual directories. Potentially useful if we ever want to support, say, gcc 4.8 or 4.9's new warnings when building with an external toolchain (but such support not yet committed). Document the bsd.compiler.mk interface.
2014-05-10 16:37:44 +00:00
.if !defined(COMPILER_VERSION)
COMPILER_VERSION!=echo ${_v:M[1-9].[0-9]*} | awk -F. '{print $$1 * 10000 + $$2 * 100 + $$3;}'
.endif
.undef _v
${CC} --version doesn't need to be queried if both COMPILER_TYPE and COMPILER_VERSION are known
2014-12-06 04:02:56 +00:00
.endif
Add a COMPILER_FEATURES variable that is set in bsd.compiler.mk. When the compiler is clang add c++11 to COMPILER_FEATURES. When the compiler supports c++11, default to building libc++. This will not impact the compliation of programs, but will make it easier for users with clang compiled systems to test libc++ by passing -stdlib=libc++ to their c++ compliations.
2012-09-26 17:25:15 +00:00
When using an external toolchain note that gcc 4.8+ supports C++11 Submitted by: imp
2014-10-21 19:58:23 +00:00
.if ${COMPILER_TYPE} == "clang" || \
(${COMPILER_TYPE} == "gcc" && ${COMPILER_VERSION} >= 40800)
Add a COMPILER_FEATURES variable that is set in bsd.compiler.mk. When the compiler is clang add c++11 to COMPILER_FEATURES. When the compiler supports c++11, default to building libc++. This will not impact the compliation of programs, but will make it easier for users with clang compiled systems to test libc++ by passing -stdlib=libc++ to their c++ compliations.
2012-09-26 17:25:15 +00:00
COMPILER_FEATURES= c++11
.else
COMPILER_FEATURES=
.endif
bsd.compiler.mk was implicitly included by bsd.own.mk in historical versions. With its movement to src.opts.mk, bsd.prog.mk was testing COMPILER_TYPE without including the bsd.compiler.mk anymore. In the source tree, this caused no problems, for reasons that aren't clear, but does cause problems outside of the source tree. Allow bsd.compiler.mk to be included multiple times safely, and always include bsd.compiler.mk at the top of bsd.prog.mk. Resist the urge to put it in bsd.init.mk, since that would reintroduce the implicit include.
2014-05-07 18:15:02 +00:00
.endif # !target(__<bsd.compiler.mk>__)
Reference in New Issue Copy Permalink