From owner-freebsd-ports@FreeBSD.ORG Sun Aug 29 08:37:48 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E893D1065698 for ; Sun, 29 Aug 2010 08:37:48 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 74EA08FC0C for ; Sun, 29 Aug 2010 08:37:48 +0000 (UTC) Received: by wwb34 with SMTP id 34so3982415wwb.31 for ; Sun, 29 Aug 2010 01:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=oOUkjDI8zSXBCLh82U/XUJgCb3gA0zwvb4ciQwh1j9Q=; b=PUDeP4EzhjaQWrLaiTYjobEyaSd33mZspOHRhlB3CL6wT1JRSguLxBNxarc4WSJpBI 0kgtkrJKRXs+lTQBq3hZNJhcYQTxenk5LMyX4EdDsgEp/cTCQOY/xNDPKaZv3aUc21FA g87wn8Sa7wsv7ZbJ3oIewfaIYMEFcMrsUCbUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=EnQe8Mqrt3lBDgzv3kNfTXT56DJwgKBxRY5vkCwsQDNW4tFzNi/aRwZMsL7YvTcaMQ /q89gofAA3bGTJ98QfgHiSNjhz72629IUG/yw7BwVElWcrNBxM1K7HAs8ifD9qGj5deq L0tx7Yrx8WiiqK8eMiSWLYxC+LpkYyoHVVBMo= Received: by 10.227.142.84 with SMTP id p20mr3137136wbu.182.1283071067306; Sun, 29 Aug 2010 01:37:47 -0700 (PDT) Received: from dragon.dg (41-132-25-181.dsl.mweb.co.za [41.132.25.181]) by mx.google.com with ESMTPS id k7sm3631012wej.26.2010.08.29.01.37.33 (version=SSLv3 cipher=RC4-MD5); Sun, 29 Aug 2010 01:37:46 -0700 (PDT) From: David Naylor Organization: Private To: Greg Lewis , freebsd-ports@freebsd.org Date: Sun, 29 Aug 2010 10:37:37 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.4.5; amd64; ; ) References: <201006251808.29467.naylor.b.david@gmail.com> <86lj7q31s8.fsf@gmail.com> <20100828213022.GA78573@misty.eyesbeyond.com> In-Reply-To: <20100828213022.GA78573@misty.eyesbeyond.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3343707.kzPFGT3LFV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008291037.40908.naylor.b.david@gmail.com> Cc: Anonymous Subject: Re: MAKE_JOBS and openjdk6 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, 29 Aug 2010 08:37:49 -0000 --nextPart3343707.kzPFGT3LFV Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Saturday 28 August 2010 23:30:22 Greg Lewis wrote: > On Sun, Aug 29, 2010 at 12:44:39AM +0400, Anonymous wrote: > > Greg Lewis writes: > > > I would argue that overriding a private variable is a hack (other por= ts > > > doing it doesn't make it not a hack). > >=20 > > You could've spoke up in ports/148754 about your concern in order for > > portmgr@ to notice. The PR strived to be less intrusive than divorcing > > build jobs from make jobs. Besides, I think adding more clutter to > > Makefiles defeats purpose of having stuff in bsd.port.mk. >=20 > In that case, whichever way you cut it, we're deliberately trying to > circumvent what is in bsd.port.mk. The circumvention is required because bsd.port.mk assumes a certain interfa= ce=20 that may not be applicable for all ports. =20 > > > Alternative patch attached which seems to achieve the same result from > > > my perspective without overriding _MAKE_JOBS. > >=20 > > Hardcoding kern.smp.cpus and ignoring MAKE_JOBS_SAFE/UNSAFE doesn't seem > > like a less hacky solution. I'd argue that it's more confusing because > > MAKE_JOBS_UNSAFE is not equal to DISABLE_MAKE_JOBS. >=20 > The patch I attached (a) does not ignore MAKE_JOBS_{SAFE,UNSAFE} and (b) > the first patch similarly uses DISABLE_MAKE_JOBS. >=20 > The first patch does the following: >=20 > 1. Sets MAKE_JOBS_SAFE _erroneously_ (the port is _not_ MAKE_JOBS_SAFE) > purely so it can force the setting of MAKE_JOBS_NUMBER. Yes and no. The port is partially MAKE_JOBS_SAFE and is able to build some= of=20 the code using make jobs. This is similar to python26: it is _SAFE but onl= y a=20 small portion of the build actually uses more than one job which in effect= =20 makes it the same as _UNSAFE (from a performance perspective). =20 > 2. Overrides passing of -j to the make invocation by fiddling the private > variable _MAKE_JOBS, which it has to do because of (1). >=20 > The one I just provided >=20 > 1. Leaves the port correctly marked as MAKE_JOBS_UNSAFE and doesn't mess > with any private variables. Your attached patch does not explicitly define either MAKE_JOBS_(UN)SAFE. = I=20 would by happy with it being defined as _UNSAFE. If there are no other=20 problems with your patch (see my comment at the bottom) then I'm happy for= =20 this patch to be committed. =20 There will still be issues with scripts that try some form of load balancin= g=20 when building ports but either way it will not be doing what was advertised= =2E =20 Similar to python. =20 > 2. Respects MAKE_JOB_NUMBER if it is set and otherwise uses the sysctl > kern.smp.cpus, the latter being what the port _already_ does. >=20 > > > Index: Makefile > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > RCS file: /var/fcvs/ports/java/openjdk6/Makefile,v > > > retrieving revision 1.28 > > > diff -u -r1.28 Makefile > > > --- Makefile 15 Aug 2010 05:23:06 -0000 1.28 > > > +++ Makefile 28 Aug 2010 18:27:44 -0000 > > > @@ -147,8 +147,14 @@ > > >=20 > > > USE_DISPLAY=3D yes > > > .endif > > >=20 > > > -BUILD_JOBS_NUMBER!=3D ${SYSCTL} -n kern.smp.cpus > > > +.if !defined(DISABLE_MAKE_JOBS) > > > +.if defined(MAKE_JOBS_NUMBER) > > > +BUILD_JOBS_NUMBER=3D ${MAKE_JOBS_NUMBER} > > > +.else > > > +BUILD_JOBS_NUMBER=3D `${SYSCTL} -n kern.smp.cpus` > > > +.endif > > >=20 > > > MAKE_ENV+=3D HOTSPOT_BUILD_JOBS=3D${BUILD_JOBS_NUMBER} Is it safe to pass an empty HOTSPOT_BUILD_JOBS to MAKE_ENV? (i.e. when=20 DISABLE_MAKE_JOBS is defined.) =20 > > > +.endif > > >=20 > > > COPYDIRS=3D \ > > > =20 > > > hotspot/src/os/linux/launcher \ --nextPart3343707.kzPFGT3LFV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEABECAAYFAkx6HFQACgkQUaaFgP9pFrLR3QCePKUmMqX/Z3LYdk1ztJeG6m0F 1hwAnRdKJKoVR61uoByfiIKdVIOLe4hm =FYvI -----END PGP SIGNATURE----- --nextPart3343707.kzPFGT3LFV--