From owner-freebsd-current  Tue Sep  3 21:35:08 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id VAA21012
          for current-outgoing; Tue, 3 Sep 1996 21:35:08 -0700 (PDT)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA21005
          for <current@FreeBSD.org>; Tue, 3 Sep 1996 21:35:06 -0700 (PDT)
Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id VAA00700; Tue, 3 Sep 1996 21:34:14 -0700 (PDT)
To: John Polstra <jdp@polstra.com>
cc: current@FreeBSD.org, sja@tekla.fi
Subject: Re: Latest Current build failure 
In-reply-to: Your message of "Tue, 03 Sep 1996 20:46:17 PDT."
             <199609040346.UAA14084@austin.polstra.com> 
Date: Tue, 03 Sep 1996 21:34:14 -0700
Message-ID: <697.841811654@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> Somewhere on my CVSup to-do list, though, is the ability to
> specify/override supfile settings on the command line and/or thru
> the GUI.  That would be a lot more convenient than modifying your
> supfile every time.

Definitely - coolness!  Make it powerful enough to accept just about
everything on the command line and you make it a lot more
straight-forward to drive it externally (perhaps from some nice
drag-and-drop collection selector) without temp files.

Terry, of course, would request that cvsup ask an external data
abstraction layer for all its resource information, allowing
one to say things like:

% cvsup -release=cvs -host=cvsup.freebsd.org -hostbase=/home \
	-base=/usr -prefix=/home/ncvs -options delete,old \
	-coll=src-bin -coll=src-contrib -coll=ports-all

or

% cvsup
cvsup> set release cvs
cvsup> set host cvsup.freebsd.org
cvsup> <you can fill in the rest, I'm sure>
cvsup> commit
cvsup> quit

Or even drive it through an expanded version of the current GUI,
somehow.  Whether or not you actually choose to go to that level
of complexity is entirely your choice, of course. :-)

Despite the fact that I seem to be poking fun at it, I'm also in
agreement with Terry that allowing a tool to be "driven" as
generically as possible is a good thing, I'm just still waiting for
someone to contribute a "command and resource driver" library which
makes it easy to instrument new and existing applications in this way
without substantially reinventing the wheel for each and every one.
Something modelled after the X Toolkit's resource mechanism with some
command-line parsing/dispatching code thrown in would be a good start,
though some might also argue that this is already being done by a
library called libtcl.a. :-)

						Jordan