From owner-cvs-ports@FreeBSD.ORG  Fri Apr  8 15:37:10 2011
Return-Path: <owner-cvs-ports@FreeBSD.ORG>
Delivered-To: cvs-ports@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 1033)
	id B37C21065677; Fri,  8 Apr 2011 15:37:10 +0000 (UTC)
Date: Fri, 8 Apr 2011 15:37:10 +0000
From: Alexey Dokuchaev <danfe@FreeBSD.org>
To: bf1783@gmail.com
Message-ID: <20110408153710.GA28200@FreeBSD.org>
References: <201104072239.p37Md9oh031253@repoman.freebsd.org>
	<BANLkTikmUZsHNjw2Jpe8Y7v5CD6WkZGtoQ@mail.gmail.com>
	<20110408022459.GA40411@FreeBSD.org>
	<20110408023021.GA47293@FreeBSD.org>
	<BANLkTik4HrVvVNU_nBtH8Oyt=81uKjn6og@mail.gmail.com>
	<20110408035430.GA56549@FreeBSD.org>
	<BANLkTinCm=6zuzopMKi1v=5ehohOGM5nYg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <BANLkTinCm=6zuzopMKi1v=5ehohOGM5nYg@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Rene Ladan <rene@freebsd.org>, cvs-ports@freebsd.org, cvs-all@freebsd.org,
	ports-committers@freebsd.org
Subject: Re: cvs commit: ports/www/chromium Makefile
X-BeenThere: cvs-ports@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CVS commit messages for the ports tree <cvs-ports.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-ports>,
	<mailto:cvs-ports-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-ports>
List-Post: <mailto:cvs-ports@freebsd.org>
List-Help: <mailto:cvs-ports-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-ports>,
	<mailto:cvs-ports-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 15:37:10 -0000

On Fri, Apr 08, 2011 at 12:24:57PM +0000, b. f. wrote:
> I guess that we should just trust users to configure them properly.

Yes, I also believe that if user wants to build a package for machine other
than theirs, they are expected to know how these things work and what to do
to get the work done.  From our side, we should provide easy and straight-
forward means of such customizations.

Summarizing our discussion, what do you think of the following?

.if ! ${MACHINE_CPU:Msse2} || defined(PACKAGE_BUILDING) && ${ARCH} != "amd64"
GYP_DEFINES+=	disable_sse2=1
.endif

Default package would have reasonable defaults now, custom port build can
be controlled by passing desired MACHINE_CPU.  Building SSE2-enabled
package for i386 is a bit tricky, but cannot be possibly polluted by
stale cached OPTIONS value.

> > On the other hand, Chromium is web browser, which it most likely is going
> > to be used on users' desktop, where SSE2 is probably feels like home for
> > a while already.  :-)
> 
> ... for those people with new hardware.  But there are still quite a
> few desktop machines that don't have SSE2, but can run modern
> web-browsers, and these machines frequently use packages built
> elsewhere.  I have a couple myself.

True.  But for this case, making default package for i386 SSE2-free
should be just what's wanted.

./danfe