From nbm@rucus.ru.ac.za Sun Sep 03 21:37:23 2000 Received: from rucus.ru.ac.za ([146.231.29.2] ident=qmailr) by ns1.sunesi.net with smtp (Exim 3.03 #1) id 13VfZz-000CiN-00 for nbm@mithrandr.moria.org; Sun, 03 Sep 2000 21:37:23 +0200 Received: (qmail 8951 invoked by uid 1003); 3 Sep 2000 19:37:21 -0000 Resent-Message-ID: <20000903193721.8950.qmail@rucus.ru.ac.za> Date: Sat, 1 May 1999 15:47:46 +0000 From: Neil Blakey-Milner To: ports@FreeBSD.org Subject: Dialog-based configuration tool for ports Message-ID: <19990501154746.A70833@rucus.ru.ac.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Resent-From: nbm@rucus.ru.ac.za Resent-Date: Sun, 3 Sep 2000 21:37:21 +0200 Resent-To: nbm@mithrandr.moria.org X-Moria-Loop: mithrandr.moria.org Content-Length: 4061 Lines: 88 Hi I've just written a tool that allows users to decide which features they'd like to enable and disable in a port build, based on a configuration file in the ports directory. It uses dialog to give the user a UI to turn on and off a bunch of options. It is a perl script. It currently resides at: http://rucus.ru.ac.za/~nbm/pdlg/pdlg (the program) http://rucus.ru.ac.za/~nbm/pdlg/pdlg.data (a data file) Usage is "./pdlg pdlg.data", data file format explained in code, options in "./pdlg -h". It's nowhere near finished, but I'd like some feedback. At the moment, there exist two basic constructs in the configuration file - classes and options. Options are binary (on/off) which when on spew out (make) input you give it. So, if you turn on SSL on the port, it'll spew out all the make code necessary to make the port include SSL support. Theoretically options can be in "radio groups" so that only one of two options can be selected at a time, although this is not implemented yet. (may be useful in ssl vs modssl decisions, &c.) Another addition may be for dialog "input boxes", and our custom "ftree"/"tree"s. Classes are collections of options as a base - ie, if you want a PHP3-enabled apache, you specify you want the "php" class from the tool, and it'll set the default options for that - I think the primary use here will be for package creation (see below). Classes can be specified on the command line, and there is a "batch" mode that doesn't use the dialog interface and instead uses the default class or the one given on the command line. In the "options" code, I convert any targets (such as post-configure or pre-build) and change them to "option-post-configure", and maintain a hash of that target in case some other option also wants to do something in post-configure, and then send out "post-configure: ssl-post-configure php-post-configure", as required. At the moment, I have one major problem. My reason in creating this tool was hopefully to break down the apache13-fp-php3-ssl-mod_perl and apache13-fp-ssl-mod-perl and apache13-php3-ssl sort of mentality (which apache13-php3 does reasonably well, and which I used as the inspiration for this program). However, I'm not enough of a make/ports guru to know whether it's possible for one make command to create multiple packages during the package creation that must occur occasionally to populate the /pub/FreeBSD/packages directory. (ie, make PACKAGE_BUILDING=1 package) Theoretically you could use a make variable "PDLG_PKG_TARGETS" and generate each "class" target in turn, build the port, install it, make the package, uninstall it, clean, and then move onto the next "class" target. (this would be in "batch" mode, which won't ask you to customize the port) In normal use, the "default" class would be used, unless changed by a make variable such as "PDLG_DEF_TARGET" (although I can't think of an immediate reason to do this, but this might be necessary to prevent loops if it's possible to create the multi-package target). The output from the command would go into "work/Makefile.pdlg.inc", unless a make variable such as "PDLG_DEF_OUTPUT" is set to elsewhere. The entire behaviour would be initiated by defining "USE_PDLG", which will (in bsd.port.mk) run the pdlg command against the pdlg data file (files/pdlg.conf, or whatever, unless changed by PDLG_FILE), and it'll conditionally include PDLG_DEF_OUTPUT if it exists (just as apache13-php3 does). Another theoretical problem is the overloading of targets like "post-configure" that the port might define itself - a "default" option that is always on might be in order to make sure this doesn't happen, yet still allow general commands in the target. I hope something like this will demystify some ports, especially those that depend on things like "BATCH" to install HTML docs (like mutt), or for ports that try to provide useful checks for definition (like NNTP_ONLY in tin) that are often overlooked. Any feedback would be most appreciated. Neil -- Neil Blakey-Milner nbm@rucus.ru.ac.za --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="portconf.2"