Date: Sun, 12 Nov 2017 19:41:04 +0700 From: Alexey Dokuchaev <danfe@nsu.ru> To: Brooks Davis <brooks@freebsd.org> Cc: ports@freebsd.org Subject: Re: RTTI support in devel/llvm40 (and maybe other llvm ports) Message-ID: <20171112124104.GA25053@regency.nsu.ru> In-Reply-To: <20171112080319.GB76223@spindle.one-eyed-alien.net> References: <20171110070748.GA27570@regency.nsu.ru> <20171112080319.GB76223@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > > > The patch is very simple (apart port revision bump): > > > > @@ -39,7 +41,7 @@ > > SUB_LIST= LLVM_PREFIX="${LLVM_PREFIX}" LLVM_SUFFIX="${LLVM_SUFFIX}" > > CMAKE_INSTALL_PREFIX= ${LLVM_PREFIX} > > -CMAKE_ARGS= -DLLVM_BUILD_LLVM_DYLIB=ON > > +CMAKE_ARGS= -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_ENABLE_RTTI=ON > > > > Could you review/commit it, and check if other LLVM ports could > > also benefit from it? Thanks, > > 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. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171112124104.GA25053>