Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 1 May 1999 15:47:46 +0000
From:      Neil Blakey-Milner <nbm@mithrandr.moria.org>
To:        ports@FreeBSD.org
Subject:   Dialog-based configuration tool for ports
Message-ID:  <19990501154746.A70833@rucus.ru.ac.za>

next in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990501154746.A70833>