Date: Sun, 3 Sep 2000 16:17:56 -0500 From: Will Andrews <will@physics.purdue.edu> To: Neil Blakey-Milner <nbm@mithrandr.moria.org> Cc: kosmos <kosmos@bowhill.yi.org>, Will Andrews <will@physics.purdue.edu>, FreeBSD Ports <ports@FreeBSD.ORG> Subject: Re: Ports Options Paper Message-ID: <20000903161756.B23702@radon.gryphonsoft.com> In-Reply-To: <20000903222835.A48384@mithrandr.moria.org>; from nbm@mithrandr.moria.org on Sun, Sep 03, 2000 at 10:28:35PM %2B0200 References: <20000903052226.E1205@radon.gryphonsoft.com> <Pine.BSF.4.21.0009031051150.1896-100000@bowhill.yi.org> <20000903222835.A48384@mithrandr.moria.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 03, 2000 at 10:28:35PM +0200, Neil Blakey-Milner wrote:
> Attached find my original mails on the subject.
I apologize for any and all misinformation. :-)
Please don't flame me for never following up to these emails, because
back then I wasn't even concerned with the fundamental structure of
ports. And when time came around and I decided I wanted to help change
things, your proposal had flown over my head 9 months prior.
Hell, I should've done this for my senior project.. a lot more useful
than my pathetic attempt to help with the cardbus project..
> 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.
Yep, that's the primary purpose of my paper..
> 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.
Yes, that's sort of what I was thinking.
> 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).
That makes good sense.
> 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.
Hmm.. sounds like there'd be an easy way to specify additional targets
with this method. Which is something I couldn't figure out how to do.
How would you propose exactly molding this sort of thing into the make
macro system of bsd.port.mk?
> 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).
This seems to be an obsolete problem, isn't it?
> 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)
IMHO, this is an extremely useful feature and I suggested a solution in
my proposal. Basically, we have a temporary TARGETPKGNAME variable that
contains the default PKGNAME at first, then modifies it according to the
options specified by the user.
> 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)
Thus, a package building script could specify a default set of packages
it would like, and we can add something to rotate through a variable
(say, PKGS) until we've completed making all of the packages. It would
go through the standard make install package procedure for each target,
and so forth. Maybe it would be smarter to create different WRKDIRs for
each package name? Say, if the PKGNAME is blah-2.0, we move ${WRKDIR}
to work/blah-2.0, and the WRKSRC is modified accordingly. IMO, make
clean should not be required to build multiple packages from the same
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).
One problem I can think of would be where you'd have a port that depends
on multiple ports, and you want different options for each port. But
this problem can be alleviated (at least temporarily) through the dlg
interface, which will pop up for each port with any options etc.
Otherwise it assumes defaults for each dependency. Suggestions on how
we can allow a user to specify options/classes for each dependency etc.
would be very useful.
> 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.
Target overriding should be done on a port-by-port basis. Since we
won't have to worry about the master-slave system anymore (assuming such
things become crunched into one port as suggested), there should not be
any danger from this sort of problem.
> 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.
Yes, I hope that we finally get something in ports that makes it far
more useful.
> Any feedback would be most appreciated.
I'm really sorry that I didn't bring up this again, instead of
reinventing the wheel. :-(
[...snip...]
> I learnt dialog and now have a similarly functional console version.
>
> GUI version is at http://rucus.ru.ac.za/~nbm/portconf/pcgtk-0.01.tar.gz,
> and requires the gtk12 and libxml ports.
>
> Console is at http://rucus.ru.ac.za/~nbm/portconf/pcdlg-0.01.tar.gz,
> and requires the libxml port.
We shouldn't have any ports requirements. IMO, dialog(1) is extensible
enough and useful enough for ports-options to work. And then a perl
script can be used to generate the correct Makefile magic for a
particular need.
The only place where ports requirements are justified is for GUIs like
GTK, QT, and so forth.
> Code is ugly, untidy, and has memory leaks.
Overhauls always have these features. :-)
> A quick recap - I'm proposing either an addition in _PORT_USE, or an
> additional target using _PORT_USE, which calls a client program, which is
> expected to create Makefile.portconf (or another name, passed by make on
> the command line) from files/portconf.xml (or similarly another name),
> depending on the choices the user provides.
Yep, this is exactly what I'm looking at; just not using the XML
language, unless you can provide a way to parse something like that *IN
THE BASE SYSTEM*. I don't think it's rational to have a cat-and-mouse
game in ports where installing a dependency for the portconf stuff is a
great idea. Portconf/ports-options/whatever implementation we use
should be usable without having installed any ports beforehand.
> In batch mode, set when BATCH is set, the client program returns the
> properties given to the default (or another, passed on command line)
> class, without displaying their user-interface.
Yup..
> This Makefile.portconf is then .include'd by bsd.port.mk, and will
> allow easy and user-friendly customization of ports build, similar to
> apache13-php3, and most unlike the common hidden make variable tweaks to
> customize ports.
Yep.. exactly what I was thinking. Dirk Froemberg should probably get
credit for having the right idea. :-)
> Another bonus, theoretically, is the ability to build multiple packages
> from one port, with one command. Upon being passed the correct make
> variables on the "package" target to indicate multiple package build,
> or maybe on a "multi-package" target, make grabs a list of classes
> to build from ${PORTCONF_TARGETS} and does a "make package deinstall
> clean BATCH=1 PORTCONF_CLASS=${PORTCONF_TARGET}" for each of the given
> targets. (The targets are expected to modify PKGNAME on their own)
I love this idea! :-))
Let's get this implemented this time around.
Hoping this discussion doesn't turn into a bikeshed,
--
Will Andrews <will@physics.purdue.edu> <will@FreeBSD.org>
GCS/E/S @d- s+:+ a--- C++ UB++++$ P+ L- E--- W+ N-- !o ?K w---
O- M+ V- PS+ PE++ Y+ PGP+>+++ t++ 5 X+ R+ tv+ b++ DI+++ D+
G++ e>++++ h! r- y?
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?20000903161756.B23702>