From owner-freebsd-toolchain@FreeBSD.ORG Mon Sep 17 21:29:56 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A7531065674 for ; Mon, 17 Sep 2012 21:29:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 38A3A8FC1B for ; Mon, 17 Sep 2012 21:29:56 +0000 (UTC) Received: by iayy25 with SMTP id y25so7158586iay.13 for ; Mon, 17 Sep 2012 14:29:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=LCwirfIQ3M5bg5F8yt50IjujD6rfCBCAR5E5WmIv2kE=; b=iD6b+Nue+1P5kVBQyUvEeKS8OEieKjYYGLHzDYBxBXyhrMckEI/mfmEr6nCz9GAQyE ofcRYdWbswsCO0nL775wwZ4AQ9iZhigRj34jYZ3ar5DUDdNDp9sRgmpib8LrgdxadVdO m/axMPn6M58wLwaj6R5wMgMighJhJsYxqK4UUI2DTERcuXG6OYebLuPwxq1UcLPIgNU5 l3lRq03SQ/B3Y5cFIFNN8eeaoOKBkmW5P2nhSXettsBN/Tdnlb1dfg2xePc4AkKkXPrJ vEXNxdZuRAkC8EkvQPhkPmWCunYn8tRr8ux88KMzdSOoR5++1ue8/6/Hg5cwEVQZDElt kZHw== Received: by 10.50.154.164 with SMTP id vp4mr8283775igb.66.1347917395473; Mon, 17 Sep 2012 14:29:55 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id nh1sm8433198igc.11.2012.09.17.14.29.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2012 14:29:53 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120917195137.GA43564@lor.one-eyed-alien.net> Date: Mon, 17 Sep 2012 15:29:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <52BDD0E3-318A-4CD4-9BE8-0C9CBF1096A8@bsdimp.com> References: <20120917191028.GA42648@lor.one-eyed-alien.net> <0D8164DE-97A3-4870-A8DF-37E91ECFE87F@bsdimp.com> <20120917195137.GA43564@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkyzb1e37V03nu02EB/M2kpQ4tQUI+2AlQA2Oi6JMlPB3vNNWlnDgNxAlCECaT2aNQZWOii Cc: toolchain@freebsd.org Subject: Re: enabling libc++ by default when building with clang X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 21:29:56 -0000 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 >>> +.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