[ On Wednesday, January 16, 2002 at 16:52:48 (-0500), mcmahill@mtl.mit.edu wrote: ]
> Subject: Re: Simultaneous builds
>
> Maybe I'm missing something obvious here, but what happens when I have 2
> machines, 'builder1' and 'builder2' and they both access the same pkgsrc
> tree?  In the default setup, they both try to create a 'work' subdirectory
> under pkgsrc/foo/bar.  Clearly this is a conflict.

No problem.  I do that all the time myself.  I commonly do simultaneous
builds of the same modules on different machines.  Eg. just now I built
audio/mpg123 simultaneously on an i386 and a sparc, both using the same
NFS-mounted filesystem on yet another machine.

I simply set WRKOBJDIR to point to a place that is guaranteed in my
environment to be unique on each machine and then optionally re-direct
that as desired with a symlink in that place (eg. if the unique place
isn't appropriate for storing build products).

> 1) mount /usr/pkgsrc read only to avoid the links.  I dont' like this
> because I may _want_ to be able to write to pkgsrc from either machine.
> In fact I often do when I'm testing pkgs on a couple of systems (to try
> and root out LP64 and/or endian woes).

I'm not sure why you even thought of this as a potential option -- I
don't think a read-only mount will by itself do anything beneficial in
this regard (nothing I can find in pkgsrc/mk/* does anything special if
pkgsrc is mounted read-only), and while it certainly must not be a hard
requirement, it must still be an option that people can choose and which
will not necessarily limit their other options for tweaking other
unrelated parts of the pkgsrc build processes.

> 2) use unique names for the "work" link.  I never liked the OBJMACHINE
> because, especially with the a.out->ELF transition, I might have 2 sparcs
> or 2 i386en, etc that want to share pkgsrc.  Thats why I like OBJHOSTNAME.

Nope, that won't work properly either, not even with OBJHOSTNAME.

And yes, that's one of the reasons OBJMACHINE is borked in many people's
environments (not to mention every one with read-only sources and more
than a very few architectures to deal with).  (I almost always have two
machines of every architecture I build on, and I've always shared my
source tree with NFS -- OBJMACHINE has always been useless in my
environment, though figuring that out took some doing.)

OBJHOSTNAME though is no better.  It's simply a standardised way of
doing the wrong thing.  You never want to include anything even remotely
dynamic in the target of the "work" ("obj") symlink since doing so
defeats your ability to share that link when it's stored on a read-only
filesystem (or even in a shared filesystem that may or may not be
mounted read-only).  (You don't want to include the MACHINE_ARCH in the
link target either since that would require making far too many links
for read-only media, and it would limit read-only media to the
architectures known at the time the media was created.)


The only correct solution I can see that covers all scenarios equally
with no limititations other than those implicit in the OS is:

3) define WRKOBJS as a common shared pointer to a unique place on every
   host sharing a given pkgsrc tree:

	$ grep WRKOBJDIR /etc/mk.conf
	WRKOBJDIR=              /var/package-obj
	$ ls -l /var/package-obj                                           
	lrwxr-xr-x  1 root  wheel  20 Jul  8  2001 /var/package-obj -> ../build/package-obj

Obviously when you do this you don't want to remove the "work" links
when you run "make clean" either (not even with OBJMACHINE), lest you do
so in a writable filesystem on one machine while another is in the
middle of building the same module.  Thus my suggested patch.....   :-)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>