[ On Thursday, November 29, 2001 at 12:26:56 (-0500), Todd Vierling wrote: ]
> Subject: Re: Toolchain Update (27-Nov-2001) 
>
> Sure, you can put whatever you like in it.  However, it *is* reasonable to
> assume that src may affect the build procedure of any alien tree you put
> inside it (see below).

I think I'm with Robert and Lennart on this one, though as I'll
elaborate below I think I do understand the quandry of this problem.
Just because something is introduced into a hierarchy doesn't mean other
things in that same hierarchy should affect it.

I don't do so at the moment, but I once had a structure like this on my
own build systems:

	/usr/src/
		Makefile	- the system source top makefile
		bin/		- source for utilities/files in /bin
		.
		.
		.
		local/		- source for stuff in /usr/local
		pkgsrc/		- pkgsrc modules for stuff in /usr/pkg

The system source shouldn't care about foreign directories simply
because its makefiles should never see them.  I.e. /usr/src/Makefile
doesn't list /usr/src/local and so it should never delve into it or even
notice that it exists.  For the same reasons makefiles within any
foreign directories should not be affected (adversely) by rules defined
by the system source makefiles.

Ah ha, I think see the root cause of the problem -- the pkgsrc makefiles
themselves use the same <bsd.own.mk> stuff as the system build stuff
does, and it's in there that 'build.sh' is found when setting the macro
${_SRC_TOP_}.

I think if we simply also turn off the USETOOLS part of the "src" magic
".ifdef BSD_PKG_MK" then both the pkgsrc makefiles will work properly
and *BSD-style builds can also be used safely by packages.  To do the
latter we can probably get away with just passing the BSD_PKG_MK
definition down to packages and that should similarly explicitly turn
off USETOOLS for any pacakge builds that use system <bsd.*.mk> files.

BTW, why not use the already defined BSDSRCDIR instead of searching for
it in the magic _SRC_TOP_ way?  If ${.CURDIR} is a proper subdirectory
of ${BSDSRCDIR} (based on being a matching substring with a terminating
'/' on each), then just look for 'build.sh' in ${BSDSRCDIR}, otherwise
do nothing!  This magic searching of all parent directories shouldn't
ever be necessary at all.  Since BSDSRCDIR cannot be a symlink and if
/bin/pwd is always used to find ${.CURDIR} then there should be no worry
that a substring match won't be a safe and sure test.

If there's magic enabled by starting make at the top of the "src"
hierarchy then that's one thing, but to have make automatically search
around in all parent directories and to use the existance of an
extremely non-descript file named 'build.sh' (and a similarly
non-descript directory named 'tools') to detect what hierarchy it might
have been started in is far too much magic, even without the potential
for collision of unrelated stuff using <bsd.*.mk> files but not wanting
to USETOOLS by default.


> "pkgsrc" does not live one level below "src" -- it lives at the same
> directory level.  It is not meant to be mergeable with "src".

I hope you meant "at the same conceptual level" -- literally pkgsrc
should be usable anywhere and any number of instances should co-exist.
Similarly src should be usable anywehre and in multiple instances.

I'm beginning to think /etc/mk.conf should only be used for things in
<sys.mk> and that all <bsd.*.mk> stuff should look first for a mk.conf
file in ${BSDSRCDIR} just like pkgsrc now uses a relative
'bsd.pkg.defaults.mk' file.  (and pkgsrc/mk/bsd.* files should be
renamed to pkgsrc/pkg.* too!)

> This is pretty standard treatment in the software world.
> 
> Source trees are set up to contain a specific set of subcomponents.  The
> parent package's maintainer has no responsibility (in most cases, no
> *ability*) to know that you put extra alien sources in its tree; it's up to
> you to deal with changes in the parent's build structure which affect you.

Hmmm...  If you alter the parent hierarchy's build system to trigger a
build in the "alien" directory then that's true, otherwise it really
shouldn't be....

-- 
							Greg A. Woods

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