From owner-freebsd-ports Tue Jun 25 6:48: 4 2002 Delivered-To: freebsd-ports@freebsd.org Received: from phoenix.dmnstech.net (phoenix.dmnstech.net [194.19.34.94]) by hub.freebsd.org (Postfix) with SMTP id 7AE6837B405; Tue, 25 Jun 2002 06:47:54 -0700 (PDT) Received: (from eivind@localhost) by phoenix.dmnstech.net (8.12.2/8.11.6) id g5PDleFB056832; Tue, 25 Jun 2002 15:47:40 +0200 (CEST) (envelope-from eivind) Date: Tue, 25 Jun 2002 15:47:40 +0200 From: Eivind Eklund To: Andy Sparrow Cc: Maxim Sobolev , ports@FreeBSD.ORG Subject: Re: 'make menuconfig' or how WITH_* can be good for you [patch] Message-ID: <20020625154740.A55185@phoenix.dmnstech.net> References: <20020625025001.4135C3E22@CRWdog.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020625025001.4135C3E22@CRWdog.demon.co.uk>; from spadger@best.com on Mon, Jun 24, 2002 at 10:50:01PM -0400 Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org First of all: Thanks for the feedback - even if I do not agree with all of it, I *do* appreciate it. On Mon, Jun 24, 2002 at 10:50:01PM -0400, Andy Sparrow wrote: > > That's what I've done. > > > > > Actually, I don't see the need to add another file for "options". > > > Why not use the port Makefile for it? > > Hmm. Actually, if you're only trying to avoid having to type in options on the > command line every time you (re)build the package, I don't see the need for > this at all. This is not the entire point. The idea is to - Normalize information, so it is possible to make tools that work with the build options - Document what each option does. This is far from obvious in many cases. - Decrease the amount of knowledge necessary to use this. > Why not use Makefile.local instead? Here's one of mine from mplayer: > > WITH_DVD= yes > WITH_GUI= yes > WITHOUT_RUNTIME_CPUDETECTION= yes > WITH_SVGALIB= yes > WITH_OPTIMIZED_CFLAGS= yes > > Now I can just 'portupgrade' with impunity. This does the same as Makefile.options; the name difference is because I did not want to overwrite anything > > > Provide a hook for portupgrade to see the options chosen. > > Or use Makefile.local instead. > > Then it's completely transparent to both the user and portupgrade, because > it's carefully frobbed into the Ports makefile system... Makefile.local works the same as a 'make menuconfig' target that is not hooked into the build automatically, and that writes to MASTERDIR. > > > No. Just make menuconfig default except when BATCH or > > > PARALLEL_PACKAGE_BUILDING defined. > > > > That is OK. > > Please, please, do not, at least not without providing a global switch so that > they can be disabled across the board. Requirement noted in my requirements list for this project. > > > Umm. I think it best to keep selected options between builds > > > except if ${WRKDIR} is cleaned. > > > > I think it best to keep the options even if WRKDIR is cleaned; doing a clean > > rebuild of a port does not mean that you want to lose the options for it. Or > > at least it does not mean that for me. > > *cough* > > Sounds to me like what you're after is pretty much like what you get from using 'Makefile.local'? ;-) > > I understand that the RO FS is a requirement which is somewhat awkward to > work around, but doesn't it seem tantalising that Makefile.local otherwise > does everything that you want and without popping up irritating semi-GUI > dialogs? Instead, it does it by forcing me to run an irritating text editor after having read through an irritating Makefile and a set of irritating (or possible non-existing) documentation for the package that is being ported. ;-) In short: Makefile.local does not do what I want - namely, provide me with easy access to setting options, without having to use a lot of time to study the package beforehand. The combination of the options file and Makefile.local allows me to do this, but then I might as well use the CUA interface (which I find fairly convenient, but opinions differ.) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message