From owner-freebsd-ports@FreeBSD.ORG Wed Mar 26 14:11:43 2008 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D61141065674 for ; Wed, 26 Mar 2008 14:11:43 +0000 (UTC) (envelope-from pav@FreeBSD.org) Received: from raven.customer.vol.cz (raven.customer.vol.cz [195.250.144.108]) by mx1.freebsd.org (Postfix) with ESMTP id 6B8D88FC14 for ; Wed, 26 Mar 2008 14:11:43 +0000 (UTC) (envelope-from pav@FreeBSD.org) Received: from oook.cz (nobody@localhost [127.0.0.1]) by raven.customer.vol.cz (8.14.1/8.14.1) with ESMTP id m2QEBdtT092662; Wed, 26 Mar 2008 15:11:39 +0100 (CET) (envelope-from pav@FreeBSD.org) From: "Pav Lucistnik" To: Wesley Shields , Jeremy Chadwick Date: Wed, 26 Mar 2008 15:11:39 +0100 Message-Id: <20080326141048.M53995@FreeBSD.org> In-Reply-To: <20080326133611.GD23226@atarininja.org> References: <20080326053328.GA29448@duncan.reilly.home> <20080326093858.GA78756@eos.sc1.parodius.com> <20080326133611.GD23226@atarininja.org> X-Mailer: OpenWebMail 2.52 20060502 X-OriginatingIP: 195.122.204.152 (cvs@oook.cz) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 X-Spam-Score: -4.399 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 195.250.144.108 Cc: ports@FreeBSD.org, Andrew Reilly Subject: Re: There is no way to know what port options mean (in general) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 14:11:43 -0000 On Wed, 26 Mar 2008 09:36:11 -0400, Wesley Shields wrote > While, it has to go somewhere and as a maintainer I have no problem > printing out a description of each option inside a custom target. > What's important is that there be some consistency in what that > target is called. Even better would be to provide a framework to > ease the work maintainers have to do. I envision the following: > > - For each available option have a variable called DESC_$FOO which > is a string which describes that option in detail. - Whatever that > target is called should be in bsd.ports.mk and output the contents > of DESC_$FOO. I think best it would be to extend the OPTIONS syntax from five to six fields, adding a long description field. Two issues 1) what about backward compatibility with existing ports 2) is dialog(1) able to display such a text field? -- Pav Lucistnik