Thursday, April 12, 2007

Oh, I hate Cygwin

I usually try not to blog while I'm angry. But I'm in the middle of trying to get the Firefox source set up in the CDT on my laptop, which, of course, is running Windows (XP mind you, still not brave enough to try Vista). And it has been a struggle.

First of all, it was a bit tricky to set up the build environment. I'm using Cygwin since Firefox would really rather be built on Linux, or in a convoluted environment that involves using Cygwin but the Microsoft tool chain, which the CDT doesn't really have support for yet. Luckily I found a web page that showed how to set it up to use the cygwin compilers. It's a little out of date but a few tweaks and I was able to get Firefox built.

Now I'm trying to get the build output into the CDT so that our cool Scanner Discovery feature can parse it and set up the include paths and symbols for the indexer. That's been tricky since the Firefox build wrapped all calls to gcc with a wrapper script which deals with converting paths, I guess. I've got that fixed, but now the source file paths used by Firefox uses the cygwin paths, i.e. /cygdrive/..., which our build output parser doesn't understand. So I'll have to introduce a new parser that does the cygpath conversion.

We've had a lot of bug reports lately on cygwin. Most of them have to do with the cygwin developers deciding not to support Windows path names any more, you know, the good ol' C:\blah. I guess understand their reasoning. Cygwin is meant to be a Linux emulation environment on Windows. I don't think that was their original intention since Cygwin actually predates all this Linux popularity, but that's what it has turned into (and even their web site now says so).

The issue for the CDT is that it isn't running under the cygwin environment. It can only deal with Windows paths. So whenever we see a cygwin path, we need to convert it. Not only that, when generating makefiles for cygwin make, we need to convert Windows paths to cygwin paths. Now, we can't do that for everything on Windows since tools like MinGW gcc does use Windows paths. It's pure evil (well maybe not that evil...)

So what this really means is that supporting Cygwin with the CDT is becoming a lot of work. This is one of the reasons I want to start promoting MinGW, a much more Windows friendly port of the gnu tool chain, as the gnu environment of choice on Windows. The problem, though, is that cygwin is very popular and easier to install and seems to have much more momentum than mingw. So we will need to continue to support both. But I'd sure like to see more of that momentum shift to MinGW. Which, in open source, that means I need to do more to help them.

10 comments:

  1. Would cygpath work for your path conversion? I first read about it on this page.

    ReplyDelete
  2. You should consider developing it on a Mac, which not only has decent shell support and GCC, but also font anti-aliasing :-)

    ReplyDelete
  3. I have applied MinGW based cross compilers to our CDT based product.
    MinGW runs faster, more stable. It keeps registry clean.
    But ... note that MinGW (or GDB) has also some minor issue around parh handling.
    Even though I think MinGW is better than Cygwin.

    Mac is good if some SWT bugs has fixed.
    (I develop plugins on PowerBook.)

    ReplyDelete
  4. If the original reason for your pain was needing Linux for compilation w/o dual-booting or having a second dedicated Linux box... have you tried VMWare? There's a lot of great canned images out there for RedHat, Debian, *ubuntu, SuSE, Gentoo... you name it, there's prolly a free image out there. It may not be as fast as cygwin (I don't know, I run MEPIS so I don't have to deal with emulation), but it might also be a less painful option.

    ReplyDelete
  5. Don't forget people doing embedded development using GNU cross compilers (e.g. ARM, MIPS etc.) on Windows/Cygwin. AFAIK, MinGW is not an option here (its x86 only right?).

    ReplyDelete
  6. Cygwin is a necessary evil in many circumstances. Having a Unixy makefile environment with zillions of small script-pieces in each rule is a little difficult to manage when your toolbox is limited to cmd.exe. (I actually tried writing a set of makefile which used Ruby as command-shell, but it never really flew...)

    I certainly hope what CDT uses cygpath if/when converting paths to/from Cygwin form. Implementing a correct cygpath converter is not trivial (BTDT!).

    ReplyDelete
  7. Hi Hugh, you have something misunderstanding about MinGW.
    As you say, Official MinGW distribution is for Win32 only. But you can build MinGW based cross complier by yourself.
    I have never tried (because I sell my MinGW based cross compiler myself), but it seems the current version of crosschains distributed by CodeSourcery is built on MinGW environment.

    A long time ago, we have some difficulties to build MinGW based crosschains. But now we can build them more easily.

    ReplyDelete
  8. At QNX we're doing the same. We found significant performance gains, in the 30% range, with our cross compilers built using MinGW.

    ReplyDelete
  9. Hi yeah i hate that too cause i dislike Cygwin it dont give me a trust feeling what i can feel is buy viagra this i can trust.

    ReplyDelete