Subject: Re: sendmail licensing again
To: None <firstname.lastname@example.org>
From: Todd Whitesel <email@example.com>
Date: 12/14/1998 00:59:05
> > 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?
While I have not actually used FreeBSD myself, I don't understand how it
could possibly have such an adverse effect on GDB. Enlighten me please?
>> 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.
Why not? You can tell GDB to debug obj/helloworld easily enough, right?
> 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.
To me cut&paste of a huge command line after you've re-run the failing make
command is not too much to ask, although certainly it could be automated more.
(History editing is your friend.) However, I agree you have a point about
editor integration. I hope to do something about this soon, by whipping up a
cheesy Tcl/Tk front-end to GDB that also knows how to do things like fire up
"xterm -e $EDITOR" using source pathnames supplied by GDB.
> 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
True enough, but the other side of this is that every time we bring in a
new version of some GNU tree, it needs to be "re-integrated" and that is
a serious pain. I much prefer the physically isolated glue file approach,
especially if it also means that the src/gnu/dist directory could be
configured and make'd just like an extracted tarball from prep.
Also the little lawyer in mind head very much prefers the physically
distinct directory structure, because it is much easier to communicate
to people than the "always put this marker in your source file" mantra
which is far easier said by you than done by all of the rest of us.
toddpw @ best.com