You have my support for the suggestion below.. That would get rid of this  
mess in the proper way.

Although, it might be very beneficial to move everything into a slightly  
different tree structure.  Having all this clutter straight under /usr is  
messy, IMHO.

I would rather have something more like /usr/obj/arch.release.suffix, with  
arch being a mandatory keyword defined by the kernel configuration process,  
release the revision of the NetBSD tree and also mandatory, as well as an  
optional user definable suffix to define derived releases.  For example:

/usr/obj/next.1.2-CURRENT/
	/next.1.1-RELEASE/
	/next.1.1-RELEASE.chk/
	/next.1.1-RELEASE.derMouse/

Munging sources and objects together in one tree sucks(TM).

Regards,
Chris

On Wed, 8 Jan 1997 13:28:56 -0800 (PST), Curt Sampson <cjs@portal.ca> wrote:
> Currently, I'm thinking the Proper Solution involves getting rid
> of the ability to have an object tree intermixed in with the source
> tree (i.e., forcing a separate obj hierarchy with symlinks in the
> source tree). While we're at it, we might as well get rid of intermixed
> architecture object trees. In other words, for source directory
>
> /usr/src/usr.sbin/config
>
> We will have object files go in to
>
> /usr/obj.sparc/usr.sbin/config
>
> We will *not* be allowed to use (any longer)
>
> /usr/src/usr.sbin/config/obj
> /usr/src/usr.sbin/config/obj.sparc
> /usr/obj/usr.sbin/config.sparc
>
> I don't know what people think of this. I don't see this as any
> loss myself.
>
> cjs
>
> Curt Sampson    cjs@portal.ca		Info at <http://www.portal.ca/
> Internet Portal Services, Inc.	
> Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.
>
>
>