From owner-freebsd-ports@FreeBSD.ORG Wed Mar 25 16:59:23 2009 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 3BEE61065670 for ; Wed, 25 Mar 2009 16:59:23 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from mail-out2.fuse.net (mail-out2.fuse.net [216.68.8.171]) by mx1.freebsd.org (Postfix) with ESMTP id EC8ED8FC1E for ; Wed, 25 Mar 2009 16:59:22 +0000 (UTC) (envelope-from cokane@FreeBSD.org) X-CNFS-Analysis: v=1.0 c=1 a=jzdkNDSjtJ4A:10 a=iigfoWBeqnYA:10 a=6I5d2MoRAAAA:8 a=DrsE8WDGdU90_3mKgI8A:9 a=637eclfsLGDvI9vZZ6okDD7KXQQA:4 a=LY0hPdMaydYA:10 a=SV7veod9ZcQA:10 a=TQIQDaZp227gW6JcrdMA:9 a=yc9w7OxhPULnOk1hON50cnDsgrgA:4 a=rPt6xJ-oxjAA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: gwout2 smtp.mail=cokane@FreeBSD.org; spf=softfail Received-SPF: softfail (gwout2: transitional domain FreeBSD.org does not designate 74.215.227.9 as permitted sender) Received: from [74.215.227.9] ([74.215.227.9:50711] helo=mail.cokane.org) by gwout2 (envelope-from ) (ecelerity 2.2.2.37 r(28805/28810M)) with ESMTP id 15/62-25989-9E26AC94; Wed, 25 Mar 2009 12:59:21 -0400 Received: from [10.128.128.2] (unknown [10.128.128.2]) by mail.cokane.org (Postfix) with ESMTPSA id BF0CA11436; Wed, 25 Mar 2009 14:03:49 -0400 (EDT) From: Coleman Kane To: Dmitry Marakasov In-Reply-To: <20090325163050.GD32386@hades.panopticon> References: <1237901632.1849.19.camel@pav.hide.vol.cz> <49C8EE21.3080702@gmail.com> <1237906449.1849.25.camel@pav.hide.vol.cz> <1237906705.1741.13.camel@localhost> <1237907945.1849.27.camel@pav.hide.vol.cz> <1237912100.1741.16.camel@localhost> <1237912382.1849.35.camel@pav.hide.vol.cz> <20090325163050.GD32386@hades.panopticon> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-kOyVzeDSAVQap3XfDcNw" Organization: FreeBSD Project Date: Wed, 25 Mar 2009 12:57:51 -0400 Message-Id: <1238000271.2543.42.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port Cc: ports@FreeBSD.org, Niclas Zeising , Pav Lucistnik Subject: Re: HEADS UP multi processor compilations for everyone 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: Wed, 25 Mar 2009 16:59:23 -0000 --=-kOyVzeDSAVQap3XfDcNw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-03-25 at 19:30 +0300, Dmitry Marakasov wrote: > * Pav Lucistnik (pav@FreeBSD.org) wrote: >=20 > > > > This would break very fast -- it's passing -j3 to port Makefile ins= tead > > > > of vendor Makefile. > > >=20 > > > This has worked fine for me for countless years, except where the > > > vendor's Makefiles were not parallel-safe. This has been my trick to = get > > > larger things (like mysql or xorg-server) to make in parallel. It *di= d* > > > work. If this has changed, then it definitely warrants mention in > > > UPDATING. > >=20 > > Then it must have worked all these years by pure chance :) >=20 > Be the way, could anyone clarify how this works? My idea was that > passing -j to port Makefile does nothing, as make/gmake on vendor's > Makefile is ran without any -j flags -> you get usual singlethreaded > build. However, I have a broken port, which uses gmake and something > like that: >=20 > sometarget: > (cd xxx; make) >=20 > and that fails with -j (make: illegal option -- -). So is there > some magic with recursive make calls and -j? >=20 When processing a Makefile, make's that support concurrent operation look for targets that will execute the $(MAKE) program. Whenever a compliant make is run (make or gmake), if it detects $(MAKE) in a rule then it will automatically expand that rule into a child process that has some sort of magical connection to the parent process. The connection allows the different make processes to share the same pool of "process count" resources amongst each other. I am not sure what the implementation is, but this communication mechanism allows child "make" processes called with "$(MAKE) ..." from inside a Makefile to globally only use N children (from -j N), and otherwise block until more "free jobs" are available amongst their shared job pool. I hope that's clear... Probably more so than the explanation given on GNU make's manual. --=20 Coleman Kane --=-kOyVzeDSAVQap3XfDcNw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAknKYooACgkQcMSxQcXat5d7mwCfSOz0Tj9tjgK8JjVtkPTt1hPI DiIAn0zf/ACrg1speJNrOa0PVwv2zJ7W =kqvg -----END PGP SIGNATURE----- --=-kOyVzeDSAVQap3XfDcNw--