Date: Tue, 25 Jun 2002 15:47:40 +0200 From: Eivind Eklund <eivind@FreeBSD.ORG> To: Andy Sparrow <spadger@best.com> Cc: Maxim Sobolev <sobomax@FreeBSD.ORG>, ports@FreeBSD.ORG Subject: Re: 'make menuconfig' or how WITH_* can be good for you [patch] Message-ID: <20020625154740.A55185@phoenix.dmnstech.net> In-Reply-To: <20020625025001.4135C3E22@CRWdog.demon.co.uk>; from spadger@best.com on Mon, Jun 24, 2002 at 10:50:01PM -0400 References: <eivind@phoenix.dmnstech.net> <20020625025001.4135C3E22@CRWdog.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020625154740.A55185>