[ On Sat, December 12, 1998 at 04:55:43 (-0800), Todd Whitesel wrote: ]
> Subject: Re: sendmail licensing again
>
> > tools work based on this assumption and so far as I know it's not
> > currently possible to get gdb, for example, to parse a PMake file and
> > learn where it should find the sources, objects, and such are (or even
> > to ask make to tell it these things are).  Not to say it can't be done,
> 
> Cooperation between GDB and 'make' is totally unnecessary.
> 
> cc -g -S hello.c
> 
> Look at hello.s; the first two ".stabs" lines should mention the working
> directory of the compiler, and the command line argument for the source file.
> 
> If GDB cannot find the source from the executable, then either you goofed or
> there is a bug that should be fixed.

Yeah, I know, but I was doing this under FreeBSD, remember?

> I don't think "ease of debugging" is a valid argument against the src/gnu
> directory -- teach your development tools how to find source files correctly.

Well, for starters you can't even begin debugging in the same directory
you run "make" from if you're using a separate object directory,
regardless of where the source lives.

Besides when using VPATH-like schemes, you still can't easily build
files without cut&paste of the often lengthy pathnames to the source.
Not everyone has such ease-of-use *all* the time.  You certainly can't
edit the files you're debugging without cut&paste either.

And in any case my point is that the use of VPATH mechanisms in the
segregated source trees makes some small portions of the source tree
look and feel and behave differently from all the rest of the source
tree (except for that one place where recursive make is not used, aka
the kernel), and all for unnecessary reasons.  There's no real reason
why the source can't be fully integrated while at the same time meeting
the needs of binary-only vendors who should obey both the letter of the
law, if not the full intent of copyright licenses similar to the FSF's
GPL.

-- 
							Greg A. Woods

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