Incorrect paths generated in Windows

Hello,

I’m currently busy compiling several gems from source on my Windows
platform. Yes, you’ve read that right, W-I-N-D-O-W-S platform :slight_smile:

Most of the gems and ruby code is compiling without issues, but
sometimes I encounter gems that have native extensions that need to be
build. To give the example i’m currently working on : Thin

Thin is relying on rake to do the configuration and installation, and
here is the problem (also occurs with make tbh). Let me copy&paste a
small piece from the Makefile generated by thin:

Start of system configuration section.

srcdir = /C/Source/git/thin/ext/thin_parser
topdir = /C/Ruby/include/ruby-1.9.1
hdrdir = /C/Ruby/include/ruby-1.9.1
arch_hdrdir = C:/Ruby/include/ruby-1.9.1/$(arch)
VPATH = $(srcdir):$(arch_hdrdir)/ruby:$(hdrdir)/ruby

The correct paths for Windows need to be like the arch_hdrdir. When I
change the above snippet into:

Start of system configuration section.

srcdir = C:/Source/git/thin/ext/thin_parser
topdir = C:/Ruby/include/ruby-1.9.1
hdrdir = C:/Ruby/include/ruby-1.9.1
arch_hdrdir = C:/Ruby/include/ruby-1.9.1/$(arch)
VPATH = $(srcdir):$(arch_hdrdir)/ruby:$(hdrdir)/ruby

The make works without any problem. So as long as a GEM relies on Make
instead of rake, I’m able to manually compile and install these gems.
However with rake, i’m unable to make these changes, because the the
file is regenerated on every call and I cannot alter these paths.

I’d like to know if this behavior is intended, or is actually a bug
inside the code that generates the paths on a Windows machine?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 11.05.2011 09:56, schrieb Arne De Herdt:

here is the problem (also occurs with make tbh). Let me copy&paste a
The correct paths for Windows need to be like the arch_hdrdir. When I
The make works without any problem. So as long as a GEM relies on Make
instead of rake, I’m able to manually compile and install these gems.
However with rake, i’m unable to make these changes, because the the
file is regenerated on every call and I cannot alter these paths.

I’d like to know if this behavior is intended, or is actually a bug
inside the code that generates the paths on a Windows machine?

As far as I can see, these paths are intended to work with the MSYS
environment of the MinGW project (MSYS provides an unix-like shell for
Windows). MSYS maps drive letters to paths under the root directory,
i.e.:

C: -> /c
D: -> /d
C:\WINDOWS -> /c/WINDOWS
etc.

Btw. this behviour is inherited from Cygwin.

If you try to compile from the MSYS shell, it may work for you.

Vale,
Marvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNymhMAAoJELh1XLHFkqha7tEH/0jhVa55QCT+2SwZlk/oVU9K
lx9J6O1Glj/THuIS3INVqhaUDPB81/dn5gyiqd7gNKH3b/4GZluFBvlmnSpMV75W
os5e+aPZxjSh+AQJbM5hVO+tojo7Y16njjYCfPUyLiX7COgj9UJBIL8hdLUnVOkD
mzt/4ppDeKK7+hH0szxbsbFa50kI655So0ietFtfR3EQIbV47H7UO6eY7tkeskj4
gtmFuWxysMX9NOMQPiO6oK9EQFk5R/LAH8ti4jwlt0XHCSlEdUwOBkLf2+xoQdeo
aeml5dPJmYkGDpTNMhmo+RpCYarQDTfqvvcLZPgwpARoFBlxr7lJKL0eR2lxnZk=
=Qh7x
-----END PGP SIGNATURE-----

Running from the msys shell does work. But right now I’m beeing forced
to work with multiple shells to get all commands running such as git,
msys stuff and my own windows/ruby commands.

On May 11, 4:56am, Arne De Herdt [email protected]
wrote:

Hello,

I’m currently busy compiling several gems from source on my Windows
platform. Yes, you’ve read that right, W-I-N-D-O-W-S platform :slight_smile:

Most of the gems and ruby code is compiling without issues, but
sometimes I encounter gems that have native extensions that need to be
build. To give the example i’m currently working on : Thin

I believe answered your question related to this on mongrel’s and
eventmachine issue tracker, but going to repeat them here.

VPATH = $(srcdir):$(arch_hdrdir)/ruby:$(hdrdir)/ruby

The correct paths for Windows need to be like the arch_hdrdir. When I
change the above snippet into:

You don’t need to change any path of the ones generated by mkmf when
using RubyInstaller+DevKit

MSYS (Minimal SYStem) make, a part of RubyInstaller’s DevKit
understand cygwin-like paths and normal Windows paths.

As I explained to you on the issue:

https://github.com/fauna/mongrel/issues/25

And you later clarified, you had some issues in your PATH that
interfered with the correct behavior of make and the compilation
process.

The make works without any problem. So as long as a GEM relies on Make
instead of rake, I’m able to manually compile and install these gems.
However with rake, i’m unable to make these changes, because the the
file is regenerated on every call and I cannot alter these paths.

Thin do not rely on Rake to do compilation or installation of the gem,
either does eventmachine.

Thin gemspec:
extensions:

  • ext/thin_parser/extconf.rb

eventmachine gemspec:
extensions:

  • ext/extconf.rb
  • ext/fastfilereader/extconf.rb

All are extconf.rb extension, so there is no rake involved in the
compilation, just ruby+mkmf+make

Also, thin already provides pre-compiled binaries for Windows,
removing the need to compile that particular gem.

EventMachine on the other hand do not have for version 0.12.10 (latest
stable) but RubyInstaller+DevKit can compile it without issues

(or you can install the pre-release version with gem install
eventmachine --pre) before installing Thin.

I’d like to know if this behavior is intended, or is actually a bug
inside the code that generates the paths on a Windows machine?

The paths generated by makefile are correct. That is because is using
MSYS make and not mingw32-make, which only understand Windows paths.

The decision on that was that RubyInstaller, GCC-based was incorrectly
detected by Ruby (specifically mkmf and it’s configuration files) and
generated these type of makefiles.

But as I mentioned before, this normally is completely transparent to
end user and as you mentioned in the mongrel issue, there was
something interfering with your path that triggered it.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs