There is no way to know what port options mean (in general)

[Wesley Shields]

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