Re: Why gdb 6.5 prints fullname in /cygdrive/... format on Windows?

[Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>]

Pedro,

>>> Eli Zaretskii  wrote:
>>> In general, if you want to avoid such problems, you should be using a
>>> coherent set of tools.  Which in practice means that a Cygwin build
>>> of GDB should be used with Cygwin front ends and other programs.  If
>>> your front end cannot be built with Cygwin, you might consider using
>>> the MinGW GCC and GDB instead, which are native Windows executables
>>> and understand Windows-style d:/foo file names.
>>>  
>>>
>> Yes, we will try to support these compilers as well in future, but 
>> our primary
>> target is to provide a free open source IDE for java and C/C++ 
>> developers,
>> and this IDE shall work with Cygwin compilers on Windows, and with many
>> other compilers on Linux, Windows and Solaris. This IDE is based on 
>> Netbeans
>> (http://netbeans.org), which is a Java application, and it is very 
>> inconvenient to
>> translate file names from Cygwin format to Windows format in Java code.
>> For gdb it takes a few microseconds to translate a file name. We have to
>> spend 250-400 milliseconds to execute external binary "cygpath -m ..."
>> and to get translated name from its output. We can try to cache the
>> directory names, but it is not correct in general case because mount
>> points can be changed, and there is no way to notice such change
>> from Java application. So, if it is possible to provide an option to
>> print fullname in Windows format, we will very much appreciate it.
>>
>
> Hummm, how about?:
> You could avoid the external executable loading time everytime you 
> want to convert a path, by keeping one "cygpath -m -f -" loaded, and 
> feeding it the pathnames to stdin / getting result from stdout.
>
Thank you, I'll try this solution. In general we are trying to balance 
between
complexity and performance in such cases :-) Dialog seems to be a more
complicated solution, because we don't know what delays can be there,
and what to do in case of timeout (restart cygpath? what if it hangs 
again?).
Also dialog is async, which means we need several threads to "talk" (at 
least
2 threads for stdin and stdout, and probably one more for stderr).
BTW, thank you for the suggestion to use "cygpath -m /..." to translate
file names! I already implemented it, and it works just fine (though the
delays are really visible :-)

Thanks,
Nik