Date: Sat, 1 May 1999 10:01:48 -0400 (EDT) From: Terry Warner <keerf@quakegods.com> To: Neil Blakey-Milner <nbm@mithrandr.moria.org> Cc: ports@FreeBSD.ORG Subject: Re: Dialog-based configuration tool for ports Message-ID: <Pine.BSI.3.91.990501100022.14252B-100000@www.netlabs.net> In-Reply-To: <19990501154746.A70833@rucus.ru.ac.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 1 May 1999, Neil Blakey-Milner wrote: > 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 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ports" in the body of the message > Me and my friend are both using this .. and as we speak my boss is looking at the code itself .. so far it seems to run ok on my friends box .. but I need to fix a few perl mods for it to run correctly on mine .. but as I said so far the program looks good .. if there is anything we can do to help .. let us know Terry Warner keerf@netlabs.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.91.990501100022.14252B-100000>