From: Luis Lavena Date: 2008-01-04T03:45:05+09:00 Subject: Re: Windows Compilation Madness On Jan 3, 3:14 pm, James Tucker wrote: > > On 2 Jan 2008, at 13:02, Gary Wright wrote: > > > No point in keeping this discussion in the Zed thread... > > Absolutely. I have been thinking about raising this topic for a long > time, but I'm also working on fixing some parts of it, so I was > holding off until I have time to complete that work. I guess though, > as it's here, now is as good a time as any. I've approached a few > people for assistance on the ideas in the past, but we're all busy > trying to survive ourselves to really get things going (yet). Even > with a lack of time, if some people want to group together, I'd be > more than happy to donate what I can to getting a more stable > environment up on the Windows platform - and that includes code I've > written against the issues. > Is funny you mention this James, it seems you made some progress since you contacted me back in november. > > Under Windows, you can compile 1.8.6 trivially on any of the compilers > mentioned. Ruby herself, in 1.8.6 is a very very clean compilation and > Just Works. The ext/* stuff however, is a different story. OpenSSL > compilation on Windows is actually a real pain - you need to get a > copy of perl if you want to use the MS compilers (if you're using the > pre-packaged build chain that is), and under MinGW you have to rebuild > the directory structure by hand, as the symlinks in the tarball will > not expand properly. I don't know why the OpenSSL devs ship their > build packages like this, I find it terribly annoying, but it is what > it is. > > As for readline, well it's broken on win32, and several of the builds > out there are archaic. GnuWin32 is useful - but again, stupid choices > make life difficult, such as the pre-compiled binaries being hardcoded > (!!!) to particular locations on disk. It's just insane - and this > isn't the fault of the operating system - this is third party > craziness. Other libs have similar issues, I won't got through the > whole ext/* stack now. zlib is easier. Getting just rubygems + ruby up > and running is quite easy, if you use one of the many pre-compiled > openssl builds out there and build + link against that. > I agree 100% on this. > There is absolutely *nothing* stopping the ruby community getting into > MinGW and helping everyone out by providing better build chains for > them based on ruby apps and capabilities. Seriously, rubys core > interpreter (1.8.6) builds really easily on top of the standard lib > under mingw and other OSes, and isn't packed up as share/buy ware like > the most commonly use perl / python builds on win32 - that's important > to some people (whatever you might think of that as a merit yourself). > More than this though, a dose of pragmatic powerful scripting > capability could go a *long* way in helping MinGW move forward, so if > anyone is interested, take a serious look at a project like this. Even > just bootstrapping the default required mingwPORT.sh files would go a > long way into making the MinGW build process simpler. I had more success downloading sources and compile by hand than using mingwPORT. After all, there is no way to automate mingwPORT execution. > What actually needs "fixing" is we need someone to release a build > chain for the build chains (for ruby herself). I'm working on > something, but I have not had time to finish it, as I'm in a busy > startup at present, so it's only good for internal use right now. I > want to try and get into working with the rubygems folks once I'm more > familiar with the chains and issues. Also interesting to join forces > with might be the multiruby and related projects (there's a build-farm > type project somewhere too but I can't remember the details, Ryan?) > Too bad we are overlapping each other on this. I though we can collaborate since both aimed the same goal, but it seems isn't. Roger Pack suggested me to bundle MinGW in a gem...: 1) a 8MB gem (!!!) 2) because mingw is inside the gem, will not be easy hook it into PATH 3) that didn't solve the rbconfig issues. > This is actually true of all the operating systems. It's very common > to have it there already on *nix, and many developers install Xcode > very early on in their configuration of a new OSX box, as this is > required for fink / macports / general open source software > compilation. This would be very similar on win32 if only mingw's build > chain wasn't so nasty at this point in time. MinGW build chain lack some docs, but is not as complex as anyone can describe it. The main issue isn't MinGW or Ruby itself, but the extensions bundled into ruby source code, which are part of the whole ruby build process. Also the dependencies used to build these extensions. Fixing the dependencies will solve the extensions issues. Regards, -- Luis Lavena