Date: Sat, 14 Jun 2014 18:55:01 +0000 From: Steve Wills <swills@freebsd.org> To: marino@freebsd.org Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, Oliver Lehmann <oliver@freebsd.org>, ports-committers@freebsd.org Subject: Re: svn commit: r357767 - head/net/cyphesis Message-ID: <20140614185459.GA68684@mouf.net> In-Reply-To: <539C8E46.1010803@marino.st> References: <201406141111.s5EBBCgV016094@svn.freebsd.org> <539C8682.3030603@marino.st> <20140614175243.GD67971@mouf.net> <539C8E46.1010803@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140614185459.GA68684>