[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: One-Click Installer: MinGW? or VC2005?

Ara.T.Howard

7/18/2006 4:13:00 PM

10 Answers

Ara.T.Howard

7/18/2006 4:42:00 PM

0

greg.kujawa

7/18/2006 4:52:00 PM

0

Good points. I ran into similar things trying to build LDAP and Qt in
Ruby on my One-Click Installer enviornment. If I was savvy and diligent
enough I would have manually compiled Ruby in a separate directory and
then used that as my environment to build other additional libraries.
Perhaps one Ruby directory for a mingw build, another for a msvc build,
another for a bcc build, etc. That way I would have my bases covered.

But I took the lazy way out and coded my LDAP solution using Python's
Win32 LDAP library that worked out of the box and found a prebuilt
binary for Qt that was released for Ruby 1.6.8 and reverted back to
that Ruby version to get Qt going on my Windows system while still
enjoying doing it using Ruby.

ara.t.how...@noaa.gov wrote:
> On Wed, 19 Jul 2006, Curt Hibbs wrote:
>
> > Thanks for taking the time to post such a detailed account. Now that you
> > mention it, I have encountered the very same problem myself with OpenSSL. I
> > actually gave up trying to solve the compile problem when I found a
> > pre-built binary for OpenSSL.
>
> right. the question is whether it's reasonable and/or healthly for the ruby
> community to require pre-built binaries for every peice of third party
> software or not? my personal feeling is that be making that requirement, no
> matter which compiler you choose, you'll see abi incompats because who knows
> what, for example, the openssl guy used. it just seems like the only way out
> is to at least provide an easy path for people who want to build stuff because
> otherwise it's like you have to get everyone, including 3rd party people and
> extension writers, to agree on one compiler and that seems, frankly,
> impossible.
>
> the caveat, however, is whether mingw can cut the mustard. i've not heard any
> reason why it couldn't - but i am simply not experience enough on windoze to
> know for sure.
>
> kind regards.
>
> -a
> --
> suffering increases your inner strength. also, the wishing for suffering
> makes the suffering disappear.
> - h.h. the 14th dali lama

Austin Ziegler

7/21/2006 3:08:00 PM

0

On 7/18/06, Curt Hibbs <ml.chibbs@gmail.com> wrote:
> Thanks for taking the time to post such a detailed account. Now that you
> mention it, I have encountered the very same problem myself with OpenSSL. I
> actually gave up trying to solve the compile problem when I found a
> pre-built binary for OpenSSL.

I'm on vacation, so of necessity my post and details will be limited.

I have *never* had a problem compiling OpenSSL. (Well, almost. They
accepted some makefile patches that I gave them to shut up bogus
warnings/errors in VC2005. After that, though, I had no problems.)

MASM is now also available as a free download, so I expect that I
could do the assembly compile, too. I might have even already done it
with the netwide assembler.

OpenSSL and zlib are good libraries to compile, and I've never had a
problem with them. The extensions are a little harder, and a lot of
makefiles are written stupidly (e.g., they run install not $(INSTALL)
which should protect you against stupid things).

To the real question, though, we *should* be using the *native*
compiler for any given platform. I would *never* use gcc on HP-UX, for
example, if I wanted anything approaching performance or
compatibility.

If there is a problem in the toolkit that *Ruby* provides for
*extensions*, we need to find ways to make the toolkit for Ruby
extensions larger. Things like GSL, however, probably need to have
bugfixes and patches filed against the GSL project to make it work
well with non-Unix platforms. There's *never* a problem with producing
your own Makefile ... or Rakefile.

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Austin Ziegler

7/21/2006 3:10:00 PM

0

On 7/18/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> the caveat, however, is whether mingw can cut the mustard. i've not heard any
> reason why it couldn't - but i am simply not experience enough on windoze to
> know for sure.

It can't. It uses an older Win32 API and still doesn't use the most
recent GCC and appears to be very slow on updating. MinGW appears to
compile significantly slower code than VC++ does, as well.

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Ara.T.Howard

7/21/2006 3:36:00 PM

0

Patrick Hurley

7/22/2006 1:17:00 AM

0

I have written a fair number of C extensions and for me it comes down
to the following:

MinGW Pro:
Much easier to build Linux/Unix libraries due to the complete tool
chain (autoconf, etc)

MinGW Con:
Uses an older buggy CRT
Questionable licensing issues

VC 2005 Pro:
Should be better optimized and tuned for the windows environment (not
saying it is, but generally vendor tool chains perform better than
gcc).
Better exposure to OS API's

VC 2005 Con:
Much harder to build many Linux/Unix libraries

------------------
I love Ruby and will use it under Linux and Win32 regardless of the
final decision that is made. I would say that if Microsoft was willing
to provide some tools or bounties on a tool chain that would allow
people using their OS to make better use of more Open Source libraries
(autoconf, bash, etc) - with their compiler at the core that would
probably be best - and while I am dreaming how do they feel about
providing a Unix like fork API <grin>.

Without that tool chain I think both sides of the debate have more or
less equal arguments and it really comes down the developers needs
(Unix tools vs tighter OS integration).

My opinion for what it is worth (not much :-)
pth

Austin Ziegler

7/22/2006 6:18:00 AM

0

On 7/21/06, Patrick Hurley <phurley@gmail.com> wrote:
> I love Ruby and will use it under Linux and Win32 regardless of the
> final decision that is made. I would say that if Microsoft was willing
> to provide some tools or bounties on a tool chain that would allow
> people using their OS to make better use of more Open Source libraries
> (autoconf, bash, etc) - with their compiler at the core that would
> probably be best - and while I am dreaming how do they feel about
> providing a Unix like fork API <grin>.

They may. I don't know. What I *can* say is that before I went on
vacation, I was on a conference call with several VC++ development
team members and they seemed interested in figuring out what can be
done to make it easier/better to build Ruby and extensions with the
latest Visual Studio.

So ... let me make a very public call: let this issue rest for a few
weeks. I am still about two weeks from finishing my vacation and I
cannot meaningfully talk to Microsoft about these and other issues
until then. I will be getting Curt and a couple of other people who
have posted exceptionally insightful posts involved with the larger
discussion. It may be that we could convince Microsoft to have a gcc
command-line compatibility mode tool or something like that. It may be
that there are other options.

The issue is most visible on Windows right now because of the
proliferation of compilers available (gcc has strangled most others on
other platforms), but the reality is that the Ruby toolchain needs to
be built better and more cross-platform. No one so far has stepped up
to do that, and I will *freely* state that I'm not qualified to do it.
Someone needs to make extconf.rb and other tools much more
platform-neutral so that we aren't bitten by people putting
compiler/platform-specific CFLAGS in their extconf.rb.

Talking about *that* would be far more productive than trying to force
the decision on MinGW or VS at this point. I have been *very*
insistent with Microsoft that whatever happens, we need to have a way
that we can end up trusting the results of someone who compiles with
MinGW (because the library that they're working on doesn't build well
with VC++) or with VS8.

That's why I've been asking for much more information than I've been
getting until this thread. Without this sort of information, I can't
show Microsoft how frustrating the situation is for Ruby developers on
Windows. Mainly because my goal is a better, faster, *more up to
date*, and more stable Ruby on Windows. I don't actually do any
extension compiling on Windows (well, not usually).

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Srinivas Jonnalagadda

7/22/2006 8:58:00 AM

0

On Sat, 2006-07-22 at 15:18 +0900, Austin Ziegler wrote:

> The issue is most visible on Windows right now because of the
> proliferation of compilers available (gcc has strangled most others on
> other platforms), but the reality is that the Ruby toolchain needs to
> be built better and more cross-platform. No one so far has stepped up
> to do that, and I will *freely* state that I'm not qualified to do it.
> Someone needs to make extconf.rb and other tools much more
> platform-neutral so that we aren't bitten by people putting
> compiler/platform-specific CFLAGS in their extconf.rb.

I have recently started looking at the possibility of converting one of
my cross-platform projects (MSVC >= 6 on Win2K, WinXP, and g++ >= 3.4 on
Red Hat/SuSE Linux) from its current build system to CMake
(http://www...).

The current build system is (mostly) automated using a set of Python
scripts. However, it is becoming increasingly difficult to maintain it.
My initial attempts at migrating a couple of sub-projects have been
successful. Indeed, the resulting CMakeLists.txt files are far simpler!

KDE project has switched recently to CMake from the auto-tools chain
(http://lwn.net/Articl...).

I do not yet know how extconf.rb really works, but could an underlying
CMake make the job of extconf.rb easier?

JS

Austin Ziegler

7/22/2006 3:26:00 PM

0

On 7/22/06, Srinivas JONNALAGADDA <srinivas.j@siritech.com> wrote:
> I do not yet know how extconf.rb really works, but could an underlying
> CMake make the job of extconf.rb easier?

Probably not. We don't want to require a P-language to compile Ruby extensions.

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

M. Edward (Ed) Borasky

7/22/2006 5:36:00 PM

0

Curt Hibbs wrote:
> I agree that that this has been a very productive discussion thread,
> and I'm
> really looking forward to working with the Microsoft team to see what
> can be
> done. We can't make a fully informed decision on this until we have
> all the
> facts in.
Is there a "MinGW team?" <ducking>