Subject: Re: Simultaneous builds
To: NetBSD Packages Technical Discussion List <tech-pkg@netbsd.org>
From: Alistair Crooks <agc@pkgsrc.org>
List: tech-pkg
Date: 01/15/2002 20:31:42
On Tue, Jan 15, 2002 at 01:18:45PM -0500, Greg A. Woods wrote:
> [ On Tuesday, January 15, 2002 at 15:35:00 (+0100), Alistair Crooks wrote: ]
> > Subject: Re: Simultaneous builds
> >
> > You may have noticed that I made some modifications to bsd.pkg.mk
> > to append the first component of the hostname to a WRKDIR, if
> > OBJHOSTNAME is defined in /etc/mk.conf. I've also committed a
> > package for the shlock utility, which can be used on Operating
> > Systems which don't have it as standard (and here I've guessed
> > at Solaris and Linux - unfortunately I can't connect to the
> > Darwin host right now to check).
> 
> There's no need to add such complication to bsd.pkg.mk.

Funny, someone thanked me the other day for adding OBJHOSTNAME,
and said it was on his list of things to do. It is hardly
"complication".  There is even a way to do this without the
OBJHOSTNAME definitions that I added, but I thought it best to
codify practice. Please remember that we don't all share your ease
of modification of bsd.pkg.mk, familiarity with make(1), or ability
to use cvs (I'm not being facetious here - just pointing out that,
often, the intended audience is people who have been handed a
machine and told to administer it). Moreover, I could have done
it without changing bsd.pkg.mk at all, by advising everyone to
set WRKDIR_BASENAME for themselves, but I prefer a handy knob for
these kind of things.

Anyway, this is the difference:

% cvs diff -r1.900 -r1.901 bsd.pkg.mk
Index: bsd.pkg.mk
===================================================================
RCS file: /cvsroot/pkgsrc/mk/bsd.pkg.mk,v
retrieving revision 1.900
retrieving revision 1.901
diff -u -r1.900 -r1.901
--- bsd.pkg.mk  2002/01/10 02:51:30     1.900
+++ bsd.pkg.mk  2002/01/11 14:41:42     1.901
@@ -1,4 +1,4 @@
-#      $NetBSD: bsd.pkg.mk,v 1.900 2002/01/10 02:51:30 jlam Exp $
+#      $NetBSD: bsd.pkg.mk,v 1.901 2002/01/11 14:41:42 agc Exp $
 #
 # This file is in the public domain.
 #
@@ -425,8 +425,15 @@
 BUILD_DIR?=            ${.CURDIR}
 .endif # WRKOBJDIR

+# If OBJHOSTNAME is set, use first component of hostname in directory name
 # If OBJMACHINE is set, use ${MACHINE_ARCH} in the working directory name
-.ifdef OBJMACHINE
+.if defined(OBJHOSTNAME)
+.  if !defined(_HOSTNAME)
+_HOSTNAME!= ${UNAME} -n
+MAKEFLAGS+= _HOSTNAME=${_HOSTNAME}
+.  endif
+WRKDIR_BASENAME?=      work.${_HOSTNAME:C|\..*||}
+.elif defined(OBJMACHINE)
 WRKDIR_BASENAME?=      work.${MACHINE_ARCH}
 .else
 WRKDIR_BASENAME?=      work
%
 
> I talked to David about this the other day by phone, but I didn't
> realise at the time the combination of shlock and the mechanism I use
> would allow both simultaneous builds on one host, as well as
> simultaneous builds on many hosts, all from one source tree, and all the
> while never requiring shlock to know about any other host.
> 
> All you need to do (I think -- I have many changes in my bsd.pkg.mk, but
> IIRC this is the only relevant one) is make the following change:
> 
> ***************
> *** 2506,2514 ****
>                 fi;                                                     \
>         fi
>   .  ifdef WRKOBJDIR
> !       -${_PKG_SILENT}${_PKG_DEBUG}                                    \
> !       ${RMDIR} ${BUILD_DIR} 2>/dev/null;                              \
> !       ${RM} -f ${WRKDIR_BASENAME}
>   .  endif
>   .endif
>   
> --- 2597,2603 ----
>                 fi;                                                     \
>         fi
>   .  ifdef WRKOBJDIR
> !       -${_PKG_SILENT}${_PKG_DEBUG}${RMDIR} ${BUILD_DIR} 2>/dev/null;
>   .  endif
>   .endif
>   
> 
> I.e. never, normally, remove the WRKOBJDIR symlink in "make clean".
> 
> Then by setting WRKOBJDIR to a host specific location you're done:
> 
> 	# if you want to build on a (fast(er)) local disk...
> 	#
> 	# This can be a symlink.
> 	#
> 	WRKOBJDIR=              /var/package-obj
> 
> 
> Note that you DO NOT EVER want to use the most broken concept of
> OBJMACHINE either (not with pkgsrc, nor with /usr/src).  You really do
> only want one and only one "work" ("obj") symlink in the source tree.

If you'd like to wrap these changes together under a suitable definition,
and send-pr them, I'm sure we'd look at them.
 
> For the same reason you really never want to use your new OBJHOSTNAME
> feature.  It's a totally unnecessary complication.

I disagree.
 
> Flexibility is best done with one simple "work" ("obj") symlink and then
> optionally further host-specific redirection with another unique symlink
> wherever that points to, for eg. I have /var/package-obj -> obj/package
> so that I can have one /var/obj partition on my build machine and yet
> share the definition of WRKOBJDIR for my shared /usr/pkgsrc.
> 
> Complete removal of OBJMACHINE from all of the build stuff for both
> /usr/pkgsrc and /usr/src would simplify things greatly and may even
> improve performance.  You sure as heck don't want to have to ship a
> /usr/src CD-ROM with 50-odd obj.${MACHINE} symlinks!  USR_OBJMACHINE
> does all that's necessary, even for cross-builds on the same host
> (USR_OBJMACHINE support might be needed in pkgsrc if pkgsrc were to ever
> support cross-builds).
> 
> I've been using the above patch for many months now and am very happy
> with it in my environment where I NFS share /usr/pkgsrc amongst many
> machines of different architectures.  I've never wanted to do
> simultaneous builds of packages on one host as David has, but with my
> scheme all that's necessary is a plain dumb "shlock" hook to keep things
> from colliding.
> 
> One could in theory write a "make wrkobjdir" target for pkgsrc, but
> that'd only be necessary if you wanted to include the symlinks in a
> read-only copy (eg. CD-ROM, "mount -t nfs -r", etc.) of the tree.  I've
> not bothered to do that yet myself.  Similarly a "make clean-wrkobjdir"
> (or whatever "make cleandir"-like) target could be written to remove the
> WRKOBJDIR links (in case you ever have to change them, or whatever).

Anyway, your mail seems to object to a small part of the changes
I'm proposing, which went in two days ago, which other people want,
and which is a convenient knob. You have not commented on the main
part of the changes at all - the shlock ones, and the splitting of
the do-extract target.

Regards,
Alistair