Date: Sun, 7 Nov 2010 20:50:26 -0500 From: Eitan Adler <lists@eitanadler.com> To: freebsd ports <freebsd-ports@freebsd.org>, portmgr@freebsd.org Subject: RFC/CFT dialog(1) replacement for ports infrastructure Message-ID: <AANLkTi=ywd3n_U80zVPTKbtvMzakEinPLhy3=6UmoMjN@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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 https://isis.poly.edu/~eitan/files/d4p-version8.2/ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=ywd3n_U80zVPTKbtvMzakEinPLhy3=6UmoMjN>