From owner-freebsd-ports@freebsd.org Sun Nov 26 16:06:48 2017 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 745D6DEA60E for ; Sun, 26 Nov 2017 16:06:48 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 591F76EB12 for ; Sun, 26 Nov 2017 16:06:48 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 554F2DEA60D; Sun, 26 Nov 2017 16:06:48 +0000 (UTC) Delivered-To: ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54DA2DEA60C for ; Sun, 26 Nov 2017 16:06:48 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 016506EB11 for ; Sun, 26 Nov 2017 16:06:47 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from Debian-exim by mx.nsu.ru with local (Exim 4.72) (envelope-from ) id 1eIzS0-0006V7-UT for ports@freebsd.org; Sun, 26 Nov 2017 23:06:36 +0700 Received: from [84.237.50.47] (helo=regency.nsu.ru) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1eIzS0-0006Us-Sw; Sun, 26 Nov 2017 23:06:36 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id vAQGFxJo086639; Sun, 26 Nov 2017 22:15:59 +0600 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id vAQGFrC4086552; Sun, 26 Nov 2017 23:15:53 +0700 (+07) (envelope-from danfe) Date: Sun, 26 Nov 2017 23:15:53 +0700 From: Alexey Dokuchaev To: Brooks Davis Cc: ports@freebsd.org Subject: Re: RTTI support in devel/llvm40 (and maybe other llvm ports) Message-ID: <20171126161553.GA85450@regency.nsu.ru> References: <20171110070748.GA27570@regency.nsu.ru> <20171112080319.GB76223@spindle.one-eyed-alien.net> <20171112124104.GA25053@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171112124104.GA25053@regency.nsu.ru> User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 3 X-KLMS-Message-Action: skipped X-KLMS-AntiSpam-Status: not scanned, whitelist X-KLMS-AntiPhishing: not scanned, whitelist X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, not scanned, whitelist X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Nov 2017 16:06:48 -0000 On Sun, Nov 12, 2017 at 07:41:04PM +0700, Alexey Dokuchaev wrote: > On Sun, Nov 12, 2017 at 08:03:19AM +0000, Brooks Davis wrote: > > On Fri, Nov 10, 2017 at 02:07:48PM +0700, Alexey Dokuchaev wrote: > > > I've just found out that our `devel/llvm40' port comes without > > > -DLLVM_ENABLE_RTTI=ON on the CMAKE_ARGS. This is a regression > > > from e.g. 3.4 times when it was enabled by default. > > > > > > The problem is that RTTI support is required by some consumers, > > > e.g. `graphics/openshadinglanguage' and `graphics/appleseed' > > > (cf. https://github.com/appleseedhq/appleseed/issues/1625), > > > but I cannot enable RTTI in those ports unless I enable it in > > > LLVM port(s) first. > > > > It's been a few years since we disabled it so I don't remember the > > details of the decision. I'll look into it, but am not in a position > > to test for breakage to other ports. > > Well it's probably OK to expect users or maintainers of those ports > would speak up if enabling RTTI breaks their software. :-) > > > IIRC there were once ports that failed to build both with and > > without so it may be that we need to wait for flavors to make this > > change. > > Hmm, that's weird: I'd expect it is easier to *not* use RTTI when > one does not need it than try to find the way around when it is not > available (which might not be possible). I also don't see why we > should wait for FLAVORS: if needed, we can always make it optional > (cf. existing EXTRAS LIT LLD LLDB options) but enabled by default. Did you have a chance to make up your mind on this? (If you worry that enabling RTTI might break some ports we can always ask portmgr@ for an exp-run). ./danfe