Subject: Re: Build identifier variable for obj dirs
To: None <tech-toolchain@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-toolchain
Date: 03/10/2002 16:26:19
[ On Saturday, March 9, 2002 at 19:08:00 (-0800), Simon J. Gerraty wrote: ]
> Subject: Re: Build identifier variable for obj dirs
>
> >> Mostly, it affects the objdir name, such that you end up with
> >> objdir names like "obj.${MACHINE}.${BUILDID}".
> 
> Greg Woods:
> >Surely you don't keep your objects in your source trees do you?  Why not
> 
> You mean you don't?

Nope, not in my NetBSD source trees anyway, excluding xsrc of course
where I still have no easy option not to (I usually also keep objects in
with my sources for projects using Automake (or GNU makefile standards)
because there the mode of operating is backwards -- you do builds from
within the objects tree, not from within the source tree -- and thus
more inconvenient for me).

>  Don't you ever debug software?

sometimes almost constantly (i.e. I sometimes only run programs under
the debugger while doing development)

I'm getting the feeling that you think the way I build my sources that
debugging is impossible or difficult or something, but that couldn't be
further from the truth.  The "obj" symlink is just as convenient for me
to use as it is for 'make' to use.

>  Or want to fiddle
> with the effects of different compiler options etc and want to switch back 
> to a previous attempt after making a minor tweak - and avoid waiting hours
> to rebuild everything?

I really don't understand what you're getting at.  Under my proposal I
too can have as many object trees as I have space for (and as many
source trees too, but the point is any given source tree can be used to
create any number of object trees).  I can choose to work with any one
of them at any time.  I don't like rebuilding things unecessarily either
-- my fastest machine takes quit a while to build even just a kernel.

> Granted there are other ways to skin any cat, but don't shoot down 
> the notion because you have no need for it.

Please (re)read my final proposal in this thread.  I think you'll find
that it doesn't really prevent anything from being achieved.

I'm only trying to show that there's no need to create an uniquely named
objdir in every source directory for every unique build (be it for a
different architecture, ala OBJMACHINE, or some other reason ala
BUILDID).  There are many reasons to only have one "obj" symlink, not
the least of which is to elegantly deal with read-only source trees, but
also there's the issue of complexity and clutter.  Wouldn't you rather
have one switch to throw rather than a thousand?  Do you want to create
a thousand new switches for every new unique build you do?

So far as I can see the only major limitation with my proposal is that
it requires either "build.sh" be used even to build one program in one
leaf directory, _or_ that MAKEOBJDIRPREFIX always be set to correspond
with BSDOBJDIR if "make" is to be used directly in a leaf directory or
sub-tree.

-- 
								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>