From owner-freebsd-ports@FreeBSD.ORG Sun Oct 3 08:22:48 2010 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B3AB106566B; Sun, 3 Oct 2010 08:22:48 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B89E38FC0C; Sun, 3 Oct 2010 08:22:47 +0000 (UTC) Received: by bwz15 with SMTP id 15so4055732bwz.13 for ; Sun, 03 Oct 2010 01:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y31CYQXzMAEuCv+ZQ5jIXQoxcaPXSWAMVYt9u8M7iAo=; b=HXlTjhAGGODJcxVpwg0hmykm6k0UaTtHLifDWMbgM9sCsCoPYSDRNkvwU1DTIqQkC3 QLQGKA7LVLTB/gZHqVSC0dabsulxAUhkEvI01IyINJG39qQW/zYLz9X/DXLTaZM+KofF rrRccZs7hBZQYomtApO40hd2peNsH4d7dxZL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fHPwC6tnAbKDGqna1f2MaPoHHai8368bh0iA/h7nzQ3czTysAd263PdQlWIdaXZXk8 gH+zb48aMRA7OKfZ9Q5Zo3EeGNFC+BKuD+miuh+g2k16gmAGnALkv64/OpQbUlETPGoY 465XM1RqTP0EE+yX9xiGl67vWIM1/JGjG3y2Y= MIME-Version: 1.0 Received: by 10.204.46.23 with SMTP id h23mr5846651bkf.75.1286094166439; Sun, 03 Oct 2010 01:22:46 -0700 (PDT) Received: by 10.204.97.208 with HTTP; Sun, 3 Oct 2010 01:22:46 -0700 (PDT) In-Reply-To: <20101002002605.GA8018@dragon.NUXI.org> References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> Date: Sun, 3 Oct 2010 10:22:46 +0200 Message-ID: From: David DEMELIER To: obrien@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Ports Subject: Re: OPTIONS (was: editors/vim installs to /) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 08:22:48 -0000 2010/10/2 David O'Brien : > On Sun, Sep 19, 2010 at 10:24:59AM +0200, David DEMELIER wrote: >> What is "sufficiently clean" ? I wonder what is not clean in the >> options framework, so please tell me then we still can clean it? > > When the Ports Collection was invented, ports maintainers were to > choose a reasonable set of configuration for the FreeBSD community > and have the port build that way. > > Today we have ports that seem to expose every single option to GNU > configure and giving the user a puzzling choice of too many things. > Often the explanations are nothing more than restating the option > name and the user is left wondering what is X? =C2=A0What does Y mean? > How do I know if I really want Z or not? =C2=A0Why is threading so often > an OPTION and not just the default? =C2=A0Why do I have to go read the > packages README and INSTALLING to figure out the caveats of say > enabling threading? =C2=A0Or what the other list of things are and their > caveats? > > 1. One should not have to deal with the OPTIONS dialog just to > 'make extract' if one wants to check the license or otherwise > investigate a port before deciding to install it. > > 2. With the way OPTIONS handling is done, there isn't a way for me > to query if I built with the defaults or not. > Thus leading to every port I manually install looking like it was > customized just because /var/db/ports/${PORTNAME} exists. =C2=A0Thus > implying I can no longer install the pre-build package. > make rmconfig ? > 3. OPTIONS are limited to only checkbox YES/NO settings. > Why can I not set PREFIX thru the OPTIONS framework and have it come > from /var/db/ports/${PORTNAME}/options on the 2nd and later builds? > Even the boolean NOPORTDOCS isn't available thru OPTIONS. > Thus it is an inconsistent way to configure a port. > I agree. As I said in 4, OPTIONS should follow the defined knob in make.conf. But for not boolean knobs there is something we can also do, spawn a little textbox to define an option with a string. Example : [X] WITH_X foo bar [ ] WITH_Y foo bar baz [fr_FR en_GB] LANGS to be build Here pressing enter on LANGS would spawn a little textbox that can be fulfilled by the user. The little problem is how to tell to OPTIONS that it's not a boolean entry. > 4. When I build misc/mc-light and have "WITHOUT_NLS=3Dyes" in > /etc/make.conf, why does the OPTIONS dialog offer me > "[X] NLS Enable gettext support" instead of defaulting the > dialog to unchecked? > I agree with this inconsistency, I think with a little of work OPTIONS framework should be to follow KNOB to enable an option if it's already defined by the user. This would be great for people that use WITHOUT_GNOME, WITHOUT_X11 and so on. I think it's possible to do it. pkgsrc do it with PKG_DEFAULT_OPTIONS=3D setting. > 5. One cannot opt-out of OPTIONS. > WITHOUT_OPTIONS does not work to just get the defaults while skipping > the OPTIONS dialog. =C2=A0Note, setting BATCH does a lot more than just > make OPTIONS non-interactive (for some ports it stops other > non-OPTIONS interaction with the user that one should see). =C2=A0Thus > there is no way to get an uninterrupted default build of something. > > 6. One cannot opt-in/opt-out on a per-port basis. > WITH[OUT]_${PORTNAME}_OPTIONS and ${PORTNAME}_WITH[OUT]_OPTIONS > should be supported to control the OPTIONS dialog just when > building ${PORTNAME}. > > 7. Setting ${PORTNAME}_WITH[OUT]_ (or > WITH[OUT]_${PORTNAME}_) should set > WITH[OUT]_ just when building ${PORTNAME}. > So that folks who don't want to be interrupted with OPTIONS every > time there is an update to the list can hardcode their choices in > /etc/make.conf. > Yes, check my answer at 4. > 8. OPTIONS make a mess in the typescript file from > 'script typescript make', and the choices are totally unreadable vs. > 'script typescript make -DWITH_FOO -WITHOUT_BAR'. > There is a disadvantages with knobs here, you must define knob each time you install/upgrade a port. Of course you can do it with the make.conf or the portconf system. OPTIONS also prints -DSOMETHING when compiling. Definitely, I like knobs and I like options. But mixing the both is painful. You should check by typing make config or sometime lsknobs or even reading the makefile. The best thing to do is switch totally to a way to configure a port and remove the other one. I think we should try to upgrade the options framework with what I said at 4. and 3. It's possible but we need some work. Kind regards, --=20 Demelier David