On Sat, Aug 28, 2010 at 02:28:02PM +0200, David Naylor wrote:
> On Friday 20 August 2010 17:12:42 Anonymous wrote:
> > Anonymous <[email protected]> writes:
> > > David Naylor <[email protected]> writes:
> > >>> %%
> > >>> Index: java/openjdk6/Makefile
> > >>>
> > >>> @@ -266,3 +267,6 @@ post-install:
> > >>> @${CAT} ${PKGMESSAGE}
> > >>>
> > >>> .include <bsd.port.post.mk>
> > >>>
> > >>> +
> > >>> +# XXX: use `?=' in bsd.port.mk
> > >>> +_MAKE_JOBS=
> > >>> %%
> > >>
> > >> Yes, I prefer this approach. See attached for the patch that does this.
> > >> I will file a PR about this shortly.
> > >
> > > I've filed ports/148754 about defining empty _MAKE_JOBS so it's not
> > > forgotten.
> >
> > That PR was recently committed. So, you can try to resurrect ports/148753.
>
> I've had a look at openjdk6 and it appears it really is MAKE_JOBS_UNSAFE.
> There are portions of it that are able to use make jobs and those are
> compiled
> using HOTSPOT_BUILD_JOBS.
>
> I suggest that either:
> - openjdk stops using HOTSPOT_BUILD_JOBS and declares itself unsafe, or
It has already declared itself unsafe.
> - declare itself make jobs safe and use HOTSPOT_BUILD_JOBS for those parts
> that can use it
>
> Attached is a patch that achieves the latter suggestion.
>
> The problem with the port as it stands now is that it breaks with
> FORCE_MAKE_JOBS, does not honour MAKE_JOBS_NUMBER and that it will consume a
> lot of resources when building, more so than what is reasonably expected.
> Simply declaring the port make jobs unsafe does not fix the resource
> consumption that some programs/scripts may take into account.
>
> Taking the first option will result in slower build times when the port is
> able
> to build faster.
>
> Taking the second option results in overriding a 'private' variable. There
> is
> precedent in ports for using that 'private' variable. With the recently
> committed changes using the 'private' variable is less intrusive.
>
> I recommend the second option. It allows the port to build as fast as
> possible, to honour MAKE_JOBS_NUMBER and does not employ any hacks.
I would argue that overriding a private variable is a hack (other ports
doing it doesn't make it not a hack).
Alternative patch attached which seems to achieve the same result from
my perspective without overriding _MAKE_JOBS.
> diff -ur /usr/ports/java/openjdk6/Makefile openjdk6/Makefile
> --- /usr/ports/java/openjdk6/Makefile 2010-07-15 22:29:26.000000000 +0200
> +++ openjdk6/Makefile 2010-07-15 22:33:45.000000000 +0200
> @@ -48,6 +48,7 @@
>
> # java extracts directly to the cwd
> WRKSRC= ${WRKDIR}
> +MAKE_JOBS_SAFE= yes
>
> USE_GMAKE= yes
> USE_MOTIF= yes
> @@ -145,8 +146,10 @@
> USE_DISPLAY= yes
> .endif
>
> -BUILD_JOBS_NUMBER!= ${SYSCTL} -n kern.smp.cpus
> -MAKE_ENV+= HOTSPOT_BUILD_JOBS=${BUILD_JOBS_NUMBER}
> +.if !defined(DISABLE_MAKE_JOBS)
> +MAKE_ENV+= HOTSPOT_BUILD_JOBS=${MAKE_JOBS_NUMBER}
> +_MAKE_JOBS=
> +.endif
>
> COPYDIRS= \
> hotspot/src/os/linux/launcher \
--
Greg Lewis Email : [email protected]
Eyes Beyond Web : http://www.eyesbeyond.com
Information Technology FreeBSD : [email protected]
Index: Makefile
===================================================================
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 @@
USE_DISPLAY= yes
.endif
-BUILD_JOBS_NUMBER!= ${SYSCTL} -n kern.smp.cpus
+.if !defined(DISABLE_MAKE_JOBS)
+.if defined(MAKE_JOBS_NUMBER)
+BUILD_JOBS_NUMBER= ${MAKE_JOBS_NUMBER}
+.else
+BUILD_JOBS_NUMBER= `${SYSCTL} -n kern.smp.cpus`
+.endif
MAKE_ENV+= HOTSPOT_BUILD_JOBS=${BUILD_JOBS_NUMBER}
+.endif
COPYDIRS= \
hotspot/src/os/linux/launcher \
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"
