Will 1.8.6 remain compiled with VC6?

Austin Ziegler wrote:

I remember the discussion was heated, but no final word on the
platform that OCI will use for future releases. So far, still remains
linked to VC6 ones.

This isn't really a core Ruby question. This should be asked on
ruby-talk or (if there is one) the One Click Installer mailing list.

What is required to finally migrate Ruby builds on Windows to VC8?

A recompile of ANY library that an extension depends on, because of
rampant Microsoft incompatibilities. The problem is that any time you
have more than one application using more than one C run-time (e.g.,
MSVCRT.DLL and MSCRT80.DLL), you have different memory allocation
tables, different file handle tables, etc. Microsoft simply DOES NOT
CARE about this and won't provide any workarounds to make this clean
and easy.

It is not in the One-Click Installer's mandate to recompile OpenSSL
using VC8 instead of VC6. Or zlib. Or pdcurses. Or ...

VC8 is the best compiler available right now and the only choice for
64-bit Windows. Maybe we can talk to Intel about using the ICC if
they'll be compatible. But Microsoft never responded positively with
any way to work around this given that we don't control the library
chain end-to-end.

It's not a problem for most of Microsoft's customers like my
workplace, where we compile EVERYTHING we need from scratch (except,
of course, Windows) or can demand up-to-date libraries from our tool
vendors (or pay for them...). It is a problem for any open source
project, not just Ruby.

-austin

Yes, let's take this to Ruby-Talk so we can all participate. Most of the open source projects I deal with on Windows have gone to || stayed with MinGW/MSYS and its friends. Ruby seems to be the exception. I remember the past discussions and my own point of view was that it didn't really matter to me as long as the gems && other C/C++ libraries were available in binary form and in source form if their licenses required it. I don't *need* to build from source on Windows, although I wouldn't refuse the opportunity to do so.

I am in the process of phasing out Cygwin usage at my day job. I brought it in as a crutch and it has become a maintenance nightmare. The worst part of it is that it hoses up file and directory permissions at the NT level if you aren't careful (and I haven't been). :slight_smile:

So while I know that VC8 is a "better" compiler than MinGW/MSYS, what other open source projects, if any, use VC8? How many others use VC6? What are the licensing gotchas on the Intel compiler? In general, are open source projects on Windows doomed to be second-class citizens? :frowning:

···

On 9/30/07, Luis Lavena <luislavena@gmail.com> wrote:

Yes, let's take this to Ruby-Talk so we can all participate. Most of the
open source projects I deal with on Windows have gone to || stayed with
MinGW/MSYS and its friends. Ruby seems to be the exception. I remember
the past discussions and my own point of view was that it didn't really
matter to me as long as the gems && other C/C++ libraries were available
in binary form and in source form if their licenses required it. I don't
*need* to build from source on Windows, although I wouldn't refuse the
opportunity to do so.

Maybe you're right, cross-posting this could get more answers from
actual ruby-mswin32 users.

The concern about gems and other C/C++ libraries in "binary form" is
why I started this.

Trying to get VC8 to compile extensions that where only available to
*nix platforms (Take for example Mongrel).

Ruby-VC6 make this a nightmare. Even VC71.

Lucky me I recovered a lost Visual Studio 97 we had on office and
installed VC6. Now mswin32 users of Mongrel have a binary gem to use
and enjoy.

So while I know that VC8 is a "better" compiler than MinGW/MSYS, what
other open source projects, if any, use VC8? How many others use VC6?

I wonder why you quoted 'better' when talking about VC8 :slight_smile:

MinGW/MSYS reduces the overwork getting something build/updated on
Windows, take as example Ruby.

I worked almost 3 days in a row to get all the Ruby dependencies (as I
listed that before) compile and properly run with VC8.

That was a huge amount of time "invested" in. On the other side, get
almost every extension bundled with ruby build under MinGW took me
less than a day (Using MinGWports and GnuWin32 source packages).

VC6 is no longer in use for Python or Subversion, both of the bigger
OSS I have seen.

Sometimes a lot of projects (like wxWindows) compiles better with
MinGW, since there is no maintainer for the nmake-compatible makefiles
or the msbuild solution files.

What are the licensing gotchas on the Intel compiler? In general, are
open source projects on Windows doomed to be second-class citizens? :frowning:

ICC requires us having a Intel license, from compiling Ruby to
creating extensions.

As I said before, the thing about VC6/VC8 is not about is the right
compiler or faster compiler, but I was considering the problems most
developers face when creating/maintaining extensions for Ruby.

···

On 30 sep, 14:57, "M. Edward (Ed) Borasky" <zn...@cesmail.net> wrote:

Yes, let's take this to Ruby-Talk so we can all participate. Most of the open source projects I deal with on Windows have gone to || stayed with MinGW/MSYS and its friends. Ruby seems to be the exception.

Postgresql 8.3 is moving to VC2005. Python also uses VC++ (2003 IIRC).

I use mingw/msys, but its not easy to setup, the tools are unfamiliar to Windows users, and debugging is well nigh impossible.

Charlie