Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Sep 2014 23:35:52 -0400
From:      Adam Weinberger <adamw@adamw.org>
To:        Alexey Dokuchaev <danfe@FreeBSD.org>
Cc:        svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, Adam Weinberger <adamw@FreeBSD.org>, ports-committers@freebsd.org
Subject:   Re: svn commit: r366936 - head/devel/avr-libc
Message-ID:  <A2778CE6-D08B-4A56-86B1-9034DDA702CF@adamw.org>
In-Reply-To: <20140902031509.GB51270@FreeBSD.org>
References:  <201409011926.s81JQ4IV011890@svn.freebsd.org> <20140902031509.GB51270@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 1 Sep, 2014, at 23:15, Alexey Dokuchaev <danfe@FreeBSD.org> wrote:

> On Mon, Sep 01, 2014 at 07:26:04PM +0000, Adam Weinberger wrote:
>> New Revision: 366936
>> URL: http://svnweb.freebsd.org/changeset/ports/366936
>>=20
>> Log:
>>  The doxygen build was failing on 8 and 9 for non-obvious reasons.
>>  As a stopgap (and as a favour to anyone building from ports ;-), =
change
>>  the DOCS option to DOXYGEN, and default it to off.
>=20
> Thanks for bringing more sanity to ports!  Doxygen should be default =
to off
> everywhere indeed.

The problem with the doxygen issue is that it only negatively affects =
people who build from ports. It=92s generally a build-time dependency =
only. For people installing from pkg, it=92s often a couple extra files, =
no big deal. Defaulting doxygen to off means that those ports produce =
packages with no (or less) documentation.

The crucially important thing, from my perspective, is that any port =
that requires doxygen HAS TO say so up front! The fact that some ports =
hide doxygen behind the DOCS option means that I have to inspect every =
single port=92s Makefile before I install it.

In fact, I think that portmgr should include making sure that doxygen =
dependencies are protected behind a DOXYGEN option instead of DOCS in =
the blanket just-fix-it. Even blanket permission to add =93(requires =
doxygen)=94 to those ports=92 DOCS_DESC would be a great start.

I=92ve said it before, it is important to maintain a consistent and =
predictable end-user experience, and that means we need to get rid of =
these sorts of gotchas.

# Adam


--=20
Adam Weinberger
adamw@adamw.org
http://www.adamw.org




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A2778CE6-D08B-4A56-86B1-9034DDA702CF>