RFC/CFT dialog(1) replacement for ports infrastructure

Eitan Adler lists at eitanadler.com
Mon Nov 8 01:50:48 UTC 2010

I've been working on a replacement for dialog(1) as used in ports for
make config.

It provides a number of benefits over the existing infrastructure
1) It supports always-on "long descriptions"
2) Supports mutually exclusive options.
3) Support's user-input freeform options
4) Supports the license infrastructure - the configuration screen
provided the ability to view and accept/reject the port's license
5) It is released under the  MIT license (thus avoiding the GPLed dialog)
6) Since it doesn't rely on dialog we have a lot more control over it.
If we needed to do something it would be easier

Please note that this is currently a backend feature only. There are
NO port facing or user facing configuration changes at this time.
bsd.options.mk would have to be changed to have this implemented.

The source code is available at
Makefile - a makefile to build the standalone binary.
               It would obviously be included in the build system with
significant changes.
dialog4ports.c - the main source file
dialog4ports.h - the main header file
nolicence.sh - runs the program without a license to accept
withlicence.sh - runs the program with a license to accept
info.txt - random junk used for testing
lic.txt - random junk used for testing
n.txt - random junk used for testing

I've been discussing this program on EFnet's #bsdports with largely
positive feedback. I'm now looking for more eyes to review the program
and more people to test it. Are there any situations on which this
program would fail?

What would it take for this tool to become the new config screen for
ports? Are there any non-bikeshead objections? If yes what can I do to
resolve them? If no what is the next step for me to take?

If you have a specific feature request for the tool and it it is
something integrable I might do it, but I want to avoid the "I want
every feature so lets put it in" problem.

A few people have asked me to turn this into a generic dialog(1)
replacement. This is not the goal of this program, but I would not
against making such a library in the future. Making such a library
requires a very different program than I had in mind - so please don't
bring this up for now. I'll consider doing it as a GSOC project.
Eitan Adler

More information about the freebsd-ports mailing list