This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Patch: rename to `insight'


> From: Tom Tromey <tromey@cygnus.com>
> Date: 29 Nov 2000 12:17:25 -0700
> 
> I assume you're talking about Windows.  I thought gdb required Cygwin
> to run on Windows, in which case you will have a shell.  Or is there a
> real native gdb?

There are two: MinGW and DJGPP.  Users of these development
environments don't always have a port of Bash installed.

> Eli> This assumes that the distribution is not moved once installed.
> Eli> That might be true on a typical Unix system (even there you might
> Eli> have problems with CD-ROM distributions), but it will make lots
> Eli> of problems on DOS/Windows systems, where a precompiled binary is
> Eli> usually installed into a directory that has nothing to do with
> Eli> the original installation at "make install" time.
> 
> The program first tries to see if `gdb' exists in the same directory
> as `insight'.  Most shells use the full path as $0, so this has a
> good chance of working.

And yet you still kept the fallback on the installation directory.  It
is this fallback that I was talking about.

> Eli> Why not simply invoke "gdb" and let PATH do its thing?  Or at
> Eli> least try that before falling back on the installation directory?
> 
> The installation directory should be the first choice (after the
> directory of `insight' itself).

I don't mind if the installation directory will be second, if PATH
is added as well, for the case where $(bindir) fails.

> Ok.  I added $(EXEEXT) to the @gdb@ substitution.

Thanks.

> Eli> Writing a short C program would eliminate all these problems (and
> Eli> also avoid requiring users to have a ported shell on their
> Eli> machines).  That's why I suggested that in the first place.
> 
> I don't know that much about Windows or DOS.  I don't know how I would
> determine whether the program was portable there.

Using portable library functions is the way to go, as always.  For
example, a call to `system' will DTRT on each OS, picking up the .exe
extension as appropriate, and looking up the PATH; `basename' knows
about system-specific directory separators, etc.  In a script you are
forced to do all that explicitly, which requires to know about all
these subtleties.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]