From owner-cvs-all@FreeBSD.ORG  Mon Sep  6 18:28:44 2010
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Delivered-To: cvs-all@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id DF1461065673;
	Mon,  6 Sep 2010 18:28:44 +0000 (UTC)
	(envelope-from gerald@pfeifer.com)
Received: from vexpert.dbai.tuwien.ac.at (vexpert.dbai.tuwien.ac.at
	[128.131.111.2])
	by mx1.freebsd.org (Postfix) with ESMTP id A04068FC1B;
	Mon,  6 Sep 2010 18:28:44 +0000 (UTC)
Received: from acrux.dbai.tuwien.ac.at (acrux.dbai.tuwien.ac.at
	[128.131.111.60])
	by vexpert.dbai.tuwien.ac.at (Postfix) with ESMTP id CCDCC1E046;
	Mon,  6 Sep 2010 20:28:41 +0200 (CEST)
Date: Mon, 6 Sep 2010 20:28:45 +0200 (CEST)
From: Gerald Pfeifer <gerald@pfeifer.com>
To: Doug Barton <dougb@FreeBSD.org>
In-Reply-To: <4C85284D.8000707@FreeBSD.org>
Message-ID: <alpine.LNX.2.00.1009062015370.17560@acrux.dbai.tuwien.ac.at>
References: <201009061123.o86BNY5u061220@repoman.freebsd.org>
	<4C85284D.8000707@FreeBSD.org>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org
Subject: Re: cvs commit: ports/emulators/wine Makefile
X-BeenThere: cvs-all@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: **OBSOLETE** CVS commit messages for the entire tree
	<cvs-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-all>
List-Post: <mailto:cvs-all@freebsd.org>
List-Help: <mailto:cvs-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2010 18:28:45 -0000

On Mon, 6 Sep 2010, Doug Barton wrote:
>> Log:
>> Explicitly configure using --without-xcomposite, --without-xinerama and
>> --without-xrandr so that builds are more reproduciable and we avoi hidden
>> dependencies when building outside of a minimal build environment, thus
>> making packages more portable.
> That sounds very reasonable. I'm just wondering if you could add OPTIONS 
> to enable those features however ...

The short answer is: yes, based on concrete user feedback I have added
and will continue to add OPTIONS.

The longer answers is: Wine itself has 44 --enable/--disable knobs and I
guess we do not want to have that many OPTIONS nor do we want to build it
with the maximum number of features and thus dependencies.  What I am
trying to do is to have those features that are relevant for most users
always built, those where I see little to no use always disabled, and 
those in between as OPTIONS.  As I receive input and suggestions from 
users, I move things between those three categories, the most common,
but not sole, move being the one from the disabled to the OPTIONS bucket.

Does that sound like a reasonable approach?


Now, for some reason in the last week or two I have received more
suggestions on this front than the entire year before, so you'll
see me and my tester busy for a few evenings. :-)

Gerald