John Heenan wrote:
It is kind of tragic when software A (eg Dev-C++ non Cygwin name file
paths) cannot communicate with software B (eg GDB compiled to use
Cygwin name file paths) without extra massaging of file paths (eg
cygpath) that may not be practical. Not only that, the label 'Cygwin
compiled' does not even guarantee consistency about how file paths are
handeled.
CCE uses a Cygwin compiled GDB with its own custom interface to GDB
that is plugged into Eclipse. It can be argued they did not need to
use a Cygwin based GDB and could have discarded the parts that cause
problems (such as readline) if they do not want to put the resources
into massaging readline etc in without Cygwin.
I disagree that you 'cannot get rid of Cygwin'. It is not needed for a
cross compiler and debugger suite. It should not be difficult to
produce a generic 'no Cygwin' cross compiler template system that can
be shared among various compiler families. Codesourcery.com have
succeeded for their GNU ARM and their source code should be a good
starting point (I have tried to downloaded the source code twice but
it was corrupted).
If codesourcery have really succeeded in doing that then maybe it is now
a realistic goal to avoid Cygwin. I seem to remember gcc and binutils
were basically OK. It was gdb that was the sticking point. If you can
actually get a clean copy and get it running, that would be very
interesting.
There was a patch for GDB version 5.1 that compiled without Cygwin and
allowed readline. I regard it a poor decision not to incorporate the
patch for future versions.
Readline is a minor issue. As you said, we had a version of GDB 5.1 that
built with MinGW and a very patched readline. It had many many other
problems with assumptions theat are made about file names. Things like
C:/fred being seen as a list of two files, in standard Unix fashion,
called C and /fred. MinGW had the same problems. It was far too big a
task to fix this for any of us to be interested.
I also suggest combining MinGW compiled and Cygwin compiled tools in a
single suite was asking for trouble. Either one or the other where
there is cross communication.
I also suggest if you want to encourage more participation and
contribution to mspgcc and similar that effort be given to solving
these 'unsexy' problems which should not exist. These tools have a
huge learning curve and time committment. I am not ashamed to say if
participants see potential for indirect financial reward (such as
through support and conultancy fees) then the attraction rockets up!
Nobody ever tried to discourage participation. So far it has been
limited. If you want to contribute, that's great.
Steve
