Date: Mon, 17 Sep 2012 15:29:51 -0600 From: Warner Losh <imp@bsdimp.com> To: Brooks Davis <brooks@freebsd.org> Cc: toolchain@freebsd.org Subject: Re: enabling libc++ by default when building with clang Message-ID: <52BDD0E3-318A-4CD4-9BE8-0C9CBF1096A8@bsdimp.com> In-Reply-To: <20120917195137.GA43564@lor.one-eyed-alien.net> References: <20120917191028.GA42648@lor.one-eyed-alien.net> <0D8164DE-97A3-4870-A8DF-37E91ECFE87F@bsdimp.com> <20120917195137.GA43564@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 17, 2012, at 1:51 PM, Brooks Davis wrote: > On Mon, Sep 17, 2012 at 01:36:53PM -0600, Warner Losh wrote: >>=20 >> On Sep 17, 2012, at 1:10 PM, Brooks Davis wrote: >>> Now that we have the COMPILER_TYPE variable I'm following up on an = idea >>> by theraven@ that we should enable libc++ by default when we are >>> building world with a compiler that supports it. The following = patch >>> implements this: >>>=20 >>> http://people.freebsd.org/~brooks/patches/libc%2b%2b-default.diff >>>=20 >>> One key question is, when do we want to throw this switch? Do we do = it >>> now so people using clang start using it sooner or do we wait until >>> we've switched the default compiler and things have settled a bit? >>>=20 >>> I suspect that we'll want to wait, but I'm curious what others = think. >>=20 >> Is the compiler type set to be the host's build, or the target's? >=20 > It's the target's compiler unless you do a make manually in a portion > of the tree. This means that if you do "make -DWITH_CLANG_IS_CC > buildworld" with this patch that you get libc++ even on a 9-STABLE > system. I think that's good. I'm mostly worried about cases where the host = system is say gcc, but the target is clang or vice versa. We've had = lots of cross threading issues with the cross build and I was hoping = this wouldn't introduce a new one. > An alternative approach here would to enhance bsd.compiler.mk to have = a > COMPILER_FEATURES variable and key off of a feature named something = like > "c++11". We'll certainly want to do something like that in the future > to support external compilers with varying features. I like this idea. For user facing features, we should have = COMPILER_VERSION keyed values of COMPILER_FEATURES so the tree can use = COMPILER_FEATURES without the user having to know that gcc 4.3 needs = what may be a longish list. Warner > -- Brooks >=20 >>=20 >> Warner >>=20 >>> -- Brooks >>>=20 >>> Index: share/mk/bsd.own.mk >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- share/mk/bsd.own.mk (revision 240466) >>> +++ share/mk/bsd.own.mk (working copy) >>> @@ -432,7 +432,6 @@ >>> ICONV \ >>> IDEA \ >>> INSTALL_AS_USER \ >>> - LIBCPLUSPLUS \ >>> NAND \ >>> OFED \ >>> SHARED_TOOLCHAIN >>> @@ -642,6 +641,33 @@ >>> .endif >>> .endfor >>>=20 >>> +# >>> +# MK_* options that default to on if the compiler is clang. >>> +# >>> +.include <bsd.compiler.mk> >>> +.for var in \ >>> + LIBCPLUSPLUS >>> +.if defined(WITH_${var}) && defined(WITHOUT_${var}) >>> +.error WITH_${var} and WITHOUT_${var} can't both be set. >>> +.endif >>> +.if defined(MK_${var}) >>> +.error MK_${var} can't be set by a user. >>> +.endif >>> +.if ${COMPILER_TYPE} =3D=3D "clang" >>> +.if defined(WITHOUT_${var}) >>> +MK_${var}:=3D no >>> +.else >>> +MK_${var}:=3D yes >>> +.endif >>> +.else >>> +.if defined(WITH_${var}) >>> +MK_${var}:=3D yes >>> +.else >>> +MK_${var}:=3D no >>> +.endif >>> +.endif >>> +.endfor >>> + >>> .if ${MK_CTF} !=3D "no" >>> CTFCONVERT_CMD=3D ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >>> .elif defined(MAKE_VERSION) && ${MAKE_VERSION} >=3D 5201111300 >>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52BDD0E3-318A-4CD4-9BE8-0C9CBF1096A8>