From owner-freebsd-ports@FreeBSD.ORG Wed Mar 26 14:17:24 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 9A8AA106566B; Wed, 26 Mar 2008 14:17:24 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 7DA858FC19; Wed, 26 Mar 2008 14:17:24 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id BB4925C2D; Wed, 26 Mar 2008 10:18:29 -0400 (EDT) Date: Wed, 26 Mar 2008 10:18:29 -0400 From: Wesley Shields To: Pav Lucistnik Message-ID: <20080326141829.GE23226@atarininja.org> References: <20080326053328.GA29448@duncan.reilly.home> <20080326093858.GA78756@eos.sc1.parodius.com> <20080326133611.GD23226@atarininja.org> <20080326141048.M53995@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080326141048.M53995@FreeBSD.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ports@FreeBSD.org, Andrew Reilly , Jeremy Chadwick 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:17:24 -0000 On Wed, Mar 26, 2008 at 03:11:39PM +0100, Pav Lucistnik wrote: > 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 The idea would be to call "make describeconfig" (or whatever it ends up being) which would output the information. If the port does not have a DESC_$FOO it will emit a string indicating that this option is not documented and to contact the maintainer to address that. > 2) is dialog(1) able to display such a text field? I was not thinking of displaying these in dialog at all, but rather similar to how "showconfig" works right now. I see no point in using dialog(1) for this as it's not really an interactive process at all, just purely informational. Sounds to me like you are thinking of including the description in the dialog. This sounds like a good idea to me and is something I can look into doing instead of my proposal. -- WXS