RTTI support in devel/llvm40 (and maybe other llvm ports)

[Alexey Dokuchaev]

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