svn commit: r357767 - head/net/cyphesis

Steve Wills swills at freebsd.org
Sat Jun 14 18:55:12 UTC 2014


On Sat, Jun 14, 2014 at 08:02:46PM +0200, John Marino wrote:
> On 6/14/2014 19:52, Steve Wills wrote:
> > On Sat, Jun 14, 2014 at 07:29:38PM +0200, John Marino wrote:
> >> On 6/14/2014 13:11, Oliver Lehmann wrote:
> >>> Author: oliver
> >>> Date: Sat Jun 14 11:11:11 2014
> >>> New Revision: 357767
> >>> URL: http://svnweb.freebsd.org/changeset/ports/357767
> >>> QAT: https://qat.redports.org/buildarchive/r357767/
> >>>
> >>> Log:
> >>>   mark as BROKEN (Does not compile with clang)
> >>>
> >>
> >>
> >> But FreeBSD 8 and 9 are still supported, and it builds on those:
> >> http://portsmon.freebsd.org/portoverview.py?category=net&portname=cyphesis
> >>
> >> So marking this unconditionally broken breaks it on those platforms, and
> >> DragonFly too.
> >>
> >> It seems to me the action to take is:
> >> 1) fix it so builds regardless of compiler
> >> 2) nothing.  (F8, F9, + DF is better than broken everywhere.
> > 
> > Wouldn't the right thing be to mark it broken on FreeBSD 8 and 9 only, via
> > conditionals?
> 
> 
> No.
> If you were going to test for anything, you'd test for clang, not the
> platform.  Secondly, what's the benefit of marking it broken?  For
> people that try to build it via source?  To save the builder the effort
> of trying?   I don't think there's much benefit and in this case,
> there's a distinct downside.

Well, first, I said that backwards...

Second, sure, testing for clang is a fine idea too.

Finally, yes, the benefit of marking it broken is all those things. Saving
build time on package builders is important. Letting people know "yes, we know
this is broken" avoids confusion and lets folks search for things that are
known broken and fix them.

What's the downside of testing for the compiler it doesn't work with and
marking it broken in that case?

Also, would adding USE_GCC help here?

Steve


More information about the svn-ports-head mailing list