From owner-cvs-ports@FreeBSD.ORG Thu Sep 8 06:22:16 2011 Return-Path: Delivered-To: cvs-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22251106564A; Thu, 8 Sep 2011 06:22:16 +0000 (UTC) (envelope-from gahr@gahr.no-ip.org) Received: from cpanel05.rubas-s05.net (cpanel05.rubas-s05.net [195.182.222.75]) by mx1.freebsd.org (Postfix) with ESMTP id 93A9A8FC0C; Thu, 8 Sep 2011 06:22:15 +0000 (UTC) Received: from 175-3.192-178.cust.bluewin.ch ([178.192.3.175] helo=gahr.no-ip.org) by cpanel05.rubas-s05.net with esmtpa (Exim 4.69) (envelope-from ) id 1R1Y06-0004qd-9Q; Thu, 08 Sep 2011 08:22:14 +0200 Received: by gahr.no-ip.org (Postfix, from userid 1001) id B9CD94505F; Thu, 8 Sep 2011 08:22:13 +0200 (CEST) Date: Thu, 8 Sep 2011 08:22:13 +0200 From: Pietro Cerutti To: Alexey Dokuchaev Message-ID: <20110908062213.GS98648@gahrfit.gahr.ch> References: <201109071436.p87EaDGo097718@repoman.freebsd.org> <20110907155741.GA69663@FreeBSD.org> <20110907160643.GR98648@gahrfit.gahr.ch> <20110908040041.GA61427@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dp9QYJgVRVEW2bsm" Content-Disposition: inline In-Reply-To: <20110908040041.GA61427@FreeBSD.org> X-PGP-Key: 0x9571F78E X-PGP-Fingerprint: 1203 92B5 3919 AF84 9B97 28D6 C0C2 6A98 9571 F78E User-Agent: Mutt/1.5.21 (2010-09-15) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel05.rubas-s05.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gahr.no-ip.org X-Source: X-Source-Args: X-Source-Dir: Cc: cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/audio/beast Makefile X-BeenThere: cvs-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gahr@FreeBSD.org List-Id: CVS commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 06:22:16 -0000 --dp9QYJgVRVEW2bsm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Sep-08, 04:00, Alexey Dokuchaev wrote: > On Wed, Sep 07, 2011 at 06:06:44PM +0200, Pietro Cerutti wrote: > > On 2011-Sep-07, 15:57, Alexey Dokuchaev wrote: > > > On Wed, Sep 07, 2011 at 02:36:13PM +0000, Pietro Cerutti wrote: > > > > gahr 2011-09-07 14:36:13 UTC > > > >=20 > > > > Modified files: > > > > audio/beast Makefile=20 > > > > Log: > > > > - Unbreak > > > > - Use sysctl to find out whether SSE is supported > > >=20 > > > What's wrong with .if ${MACHINE_CPU:Msse} ? > >=20 > > I found out that MACHINE_CPU does not reflect the actual caps of the CPU > > the process is currently running on. This leads to false negative (no > > sse in MACHINE_CPU on SSE-capable CPUs). Look at these outputs from a > > test machine of mine: > >=20 > > > make -V MACHINE_CPU > > i486 >=20 > This is correct for default CPUTYPE; it is done to ensure that default > package will be runnable on the lowest supported chip, which in case of x= 86 > is i486. Users who do not want to support ancient models (that is, they = do > not expect to run their binaries on them), are advised to set CPUTYPE in > /etc/make.conf. >=20 > > > sysctl hw.instruction_sse > > hw.instruction_sse: 1 >=20 > We should rely on what ports framework tells us about supported CPU > features. Sticking our "dirty hands" in MD stuff is bad practice and wou= ld > certainly become bogus e.g. when cross-compiling things. Even without > cross compilation, it can result in code that would fail to run on desired > CPUTYPE. >=20 > > Unfortunately, using a sysctl here is the only reliable way I found to > > determine SSE capabilities. >=20 > Capabilities of the "build box". Which is not necessarily "run box". Which is what I need here anyway. I need to determine what the build system (autoconf) will determine at build time, since the script doesn't come with a "turn SSE on/off". >=20 > > Any suggestions how to do it better is warmly welcome! >=20 > I believe the best thing is to revert this part of the change. Examining > MACHINE_CPU is standard way of checking for specific CPU feature, used in > many other ports. Your way is both inconsistent and just wrong: our build > cluster machines definitely support SSE and friends, but generate packages > for i486 -- for a reason. Your commit I believe would make such packages > unsuable for anyone with pre-SSE CPU (including this port in question). In this particular port, whether SSE is available or not decides wheter a set of SSE-enabled plugins are built, in addition to the standard plugins. The most harm will be having a handful of additional files installed, that the target machine won't be able to use. On the other hand, reverting the change means not being able to predict which files will be installed, thus having leftovers, thus having a BROKEN port. >=20 > ./danfe --=20 Pietro Cerutti The FreeBSD Project gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp --dp9QYJgVRVEW2bsm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5oXxQACgkQwMJqmJVx946QDQCgrA3xnxx8unPn8mHJSyrHQ8+O xcoAn3ArahJ8B8MkXYFdfAgS6ytTu8Jj =eOEG -----END PGP SIGNATURE----- --dp9QYJgVRVEW2bsm--