From owner-freebsd-ports@FreeBSD.ORG Wed Apr 2 19:15:26 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 8260C37B401 for ; Wed, 2 Apr 2003 19:15:26 -0800 (PST) Received: from spadger.best.vwh.net (spadger.best.vwh.net [192.220.100.249]) by mx1.FreeBSD.org (Postfix) with SMTP id F3BD143FB1 for ; Wed, 2 Apr 2003 19:15:25 -0800 (PST) (envelope-from spadger@spadger.best.vwh.net) Received: (qmail 10724 invoked by uid 25849); 3 Apr 2003 03:22:02 -0000 Date: Thu, 3 Apr 2003 03:22:02 +0000 From: Andrew Sparrow To: Kris Kennaway Message-ID: <20030403032202.A695@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> <20030402221845.A66727@spadger.best.vwh.net> <20030403014302.GC11467@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: <20030403014302.GC11467@rot13.obsecurity.org>; from kris@obsecurity.org on Wed, Apr 02, 2003 at 05:43:02PM -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: Thu, 03 Apr 2003 03:15:26 -0000 On Wed, Apr 02, 2003 at 05:43:02PM -0800, Kris Kennaway wrote: > On Wed, Apr 02, 2003 at 10:18:45PM +0000, Andrew Sparrow wrote: > > 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. > > That's what WRKDIRPREFIX is for. Of course, WRKDIR is not persistent > because it is deleted whenever you do 'make clean'. > > > (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? > > I meant that for people using a RO ports tree, Makefile.local in the > port directory is not an option. Given that this is a supported use > of the ports collection, Makefile.local cannot be a general-purpose > solution for storing local configuration state for the port. Ah, I see what you're driving at now. I'd never actually considered using a R/O ports tree and building ports locally with WRKDIRPREFIX. Probably because my sole usage of a R/O ports tree (and I'd always assumed, most peoples') is aimed at getting around two specific problems: i) Lack of local disk space ii) Lack of local grunt Thus, I build the port(s), dependancies etc with the desired options on the "host", remove the .install_done flag, NFS mount it on the target, cd into the appropriate port directory and do a "make install" on the target. Naturally, this requires care when building the port on the host machine - e.g. that CPU type and other options are correctly set. Perhaps I'm simply being unsophisticated and there's all kinds of other wonderful things you can do, but it seems to me that (i) above isn't actually being effectively addressed if you're building from a R/O ports tree - because certain ports (and especially those with honking dependancies) will use considerably more space to build than the ports tree occupies anyway. And in this scenario, problem (ii) (a significant factor on a 486 or P150 firewall/print/file/Samba/fax server with ~64MB memory and slow local disks) is just not addressed at all. Unless I'm missing something more fundamental (always possible), this manner of usage doesn't seem too useful to me - although I will grant that, for consistancy and managability, it is very nice to use (e.g.) a CD of a ports tree snapshot and update all your machines to/from the same vintage of everything. It also still seems to me that Makefile.local will still work - after all, it's above WRKDIR - however, it then takes on the flavor of global, or site-wide, options settings on a port-by-port basis, rather than the host-by-host that the name implies it was originally intended to provide. > > 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. > > I was talking about my patches which replace the ad-hoc dialog > configurators in some ports. They allow you to choose not to enter > the configurator if you don't want to. So one could run the configurator once, set any desired options to local preferences and choose that it never come up again for that port? If so, that'd be ideal - when are you committing it? ;-) Regards, AS