svn commit: r357767 - head/net/cyphesis

[John Marino]

On 6/14/2014 20:55, Steve Wills wrote:
> On Sat, Jun 14, 2014 at 08:02:46PM +0200, John Marino wrote:
>> On 6/14/2014 19:52, Steve Wills wrote:
>>> 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. 

This breaks probably 1 second after configuration.  What it saves
builders is negligible.

> Letting people know "yes, we know
> this is broken" avoids confusion and lets folks search for things that are
> known broken and fix them.

I see it the other way.
Marking it broken means no more logs.  Eventually all the logs fall out,
and nobody knows *why* it's broken.  Some people actually put the broken
part of the log in the commit message to document it, but that didn't
happen here.

So I am philosophically against a quick trigger on marking broken due to
this downside.  Sure, if it saves downloading a 100Mb distfile, it makes
sense, but if it's a 89k distfile that breaks immediately, then let it
keep breaking.

I think it's ironic that the nuisance reports meant to spur the fix of a
port actually resulted in the port getting marked broken on all
platforms rather getting fixed on the problem platforms as was the
intention.  That certainly backfired!


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

see above.


> Also, would adding USE_GCC help here?

>From what I could see of the build log, it should be relatively easy for
a knowledgeable person to fix it to work on any compiler.  A real
attempt to fix it should be made before resorting to USE_GCC.  But yes,
USE_GCC would be preferable to BROKEN IMO.

John