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 _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
