From owner-freebsd-ports@FreeBSD.ORG Wed Apr 2 14:12:19 2003 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AB3A37B401 for ; Wed, 2 Apr 2003 14:12:19 -0800 (PST) Received: from spadger.best.vwh.net (spadger.best.vwh.net [192.220.100.249]) by mx1.FreeBSD.org (Postfix) with SMTP id 9965D43F93 for ; Wed, 2 Apr 2003 14:12:16 -0800 (PST) (envelope-from spadger@spadger.best.vwh.net) Received: (qmail 95765 invoked by uid 25849); 2 Apr 2003 22:18:45 -0000 Date: Wed, 2 Apr 2003 22:18:45 +0000 From: Andrew Sparrow To: Kris Kennaway Message-ID: <20030402221845.A66727@spadger.best.vwh.net> References: <5.2.0.9.0.20030402135505.00a10ec0@127.0.0.1> <20030402081419.54AB4E2@CRWdog.demon.co.uk> <20030402201530.GB9496@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030402201530.GB9496@rot13.obsecurity.org>; from kris@obsecurity.org on Wed, Apr 02, 2003 at 12:15:30PM -0800 cc: freebsd-ports@freebsd.org Subject: Re: Setting make options permanently (WITHOUT_GNOME, etc) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 22:12:19 -0000 On Wed, Apr 02, 2003 at 12:15:30PM -0800, Kris Kennaway wrote: > On Wed, Apr 02, 2003 at 12:14:19AM -0800, Andy Sparrow wrote: > > > For some bizarre and inexplicable (at least to me) reason, everyone who > > bikesheds around Yet Another Way to provide persistant build options to > > ports completely ignores this extremely convenient, pre-existing and > > perfectly functional mechanism. > > One of the design features of the ports collection is that it can be > used read-only, e.g. mounted read-only via NFS. I know thanks. I frequently update/install ports (and/or worlds, for that matter) on my firewall that were built on a faster machine. Other than the fact it's a little difficult for the port you're installing to create .install_done.${PORT} on a R/O FS, it seems to work fine. (and, IIRC, you may need to remove the .install_done file - from the serving machine, naturally - otherwise make thinks it doesn't need to do anything). > Makefile.local cannot be used there. I don't understand what you mean. The options in the file are used to build the port. If those options are not applicable to the machine on which you install it, then that's as doomed an act on the user's part as setting the CPU architecture to P4 on the building machine (e.g. in make.conf) and then installing the resulting binaries on a 486. Could you clarify your statement if I've misunderstood what you meant? > > If I want to use BS dialogs[0] to configure things, I'll install Linux > > or Slowaris, thanks very much. I *like* setting stuff once in text > > files, and I *like* unattended, automatic, recursive-with-my-local-option > > s ports upgrades[1] after my cvsup/build/installworlds. > > Don't use it then..easy! Some ports don't provide the ability to set build-time options either via the Make command-line, make.conf, pkgconfig or Makefile.local, they will instead implicitly start a dialog and prompt the user to interact with them, halting the build. Some ports won't build dialog if BATCH is set (and they're interactive). Yet others aren't marked as INTERACTIVE, and yet collect input from the user, stalling a build. I see all of the above as bugs, personally. I would personally prefer the ports system to only invoke (e.g.) the dialog mechanism to collect interactive input if values for a minimal necessary subset of build options hadn't been set or provided. Will you consider patches to achieve the above? Would you explain why Makefile.local is not a suitable mechanism to achieve this? Regards, AS