Ruby Forum Ruby-core > [PATCH] Allow building ruby with mingw

Posted by Alexey Borzenkov (snaury)
on 19.01.2009 23:53
(Received via mailing list)
---
Hi, recently I've been trying to compile Ruby 1.8.7 with mingw and was
surprised that mkmf.rb fails to create Makefile that would work with
msys make. The reason for this is mainly VPATH that gets separated by
semicolon. And when I finally install Ruby the same happens for any
extension, only there's one more problem: paths would be something like:

  C:/Ruby/...;...

and msys make chokes on that even worse, unable to find ruby.h.

So this makes me really wonder how people are building Ruby with mingw 
and
avoid this problem? Are you using something else beside msys? Would my
patch break things for you then?

 lib/mkmf.rb |   26 ++++++++++++++++++++++----
 1 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/lib/mkmf.rb b/lib/mkmf.rb
index a532b5c..a914a48 100644
--- a/lib/mkmf.rb
+++ b/lib/mkmf.rb
@@ -1233,6 +1233,24 @@ def winsep(s)
   s.tr('/', '\\')
 end

+# Converts native path to format acceptable in Makefile
+#
+# Internal use only.
+#
+def mkintpath(path)
+  if !CROSS_COMPILING
+    case CONFIG['build_os']
+    when 'mingw32'
+      # mingw uses make from msys and it needs special care
+      # converts from C:\some\path to /C/some/path
+      path = path.dup
+      path.gsub!(/\\/, '/')
+      path.gsub!(/^\s*([A-Za-z]):(\/.*)\s*$/, '/\1\2')
+    end
+  end
+  path
+end
+
 def configuration(srcdir)
   mk = []
   vpath = %w[$(srcdir) $(topdir) $(hdrdir)]
@@ -1242,7 +1260,7 @@ def configuration(srcdir)
       if CONFIG['target_os'] != 'cygwin'
         vpath.each {|p| p.sub!(/.*/, '$(shell cygpath -u \&)')}
       end
-    when 'msdosdjgpp', 'mingw32'
+    when 'msdosdjgpp'
       CONFIG['PATH_SEPARATOR'] = ';'
     end
   end
@@ -1255,9 +1273,9 @@ if $extmk
   "top_srcdir = " + $top_srcdir.sub(%r"\A#{Regexp.quote($topdir)}/",
"$(topdir)/")
 end
 }
-srcdir = #{srcdir.gsub(/\$\((srcdir)\)|\$\{(srcdir)\}/) 
{CONFIG[$1||$2]}.quote}
-topdir = #{($extmk ? CONFIG["topdir"] : $topdir).quote}
-hdrdir = #{$extmk ? CONFIG["hdrdir"].quote : '$(topdir)'}
+srcdir = #{srcdir.gsub(/\$\((srcdir)\)|\$\{(srcdir)\}/)
{mkintpath(CONFIG[$1||$2])}.quote}
+topdir = #{mkintpath($extmk ? CONFIG["topdir"] : $topdir).quote}
+hdrdir = #{$extmk ? mkintpath(CONFIG["hdrdir"]).quote : '$(topdir)'}
 VPATH = #{vpath.join(CONFIG['PATH_SEPARATOR'])}
 }
   if $extmk
Posted by Roger Pack (Guest)
on 21.01.2009 20:12
(Received via mailing list)
>So this makes me really wonder how people are building Ruby with mingw and
avoid this problem? Are you using something else beside msys? Would my
patch break things for you then?

 Luis' mingw distro seems to work well
http://github.com/luislavena/rubyinstaller/blob/master/README.txt
http://www.akitaonrails.com/2008/7/26/still-playing-with-ruby-on-windows

At least, when I use it I can build binary gems using it. If that's any
help.
-=r
Posted by Alexey Borzenkov (snaury)
on 21.01.2009 21:55
(Received via mailing list)
On Wed, Jan 21, 2009 at 10:08 PM, Roger Pack <rogerdpack@gmail.com> 
wrote:
> Luis' mingw distro seems to work well
> http://github.com/luislavena/rubyinstaller/blob/master/README.txt
> http://www.akitaonrails.com/2008/7/26/still-playing-with-ruby-on-windows
>
> At least, when I use it I can build binary gems using it. If that's any
> help.

Aha! And I found why:

It happens to use make 3.79.1, while msys has 3.81 as the latest
version right now. In fact, I can't even find
msysCORE-1.0.11-2007.01.19-1.tar.bz2 in the msys downloads on
sourceforge anymore.

It seems that make 3.79.1 had a bug that mistakenly allowed semicolons
as VPATH separators (or was it some weird heuristics?), and that's why
many people didn't notice it before. I'm happy to announce that my
patch still works with make 3.79.1 and nothing breaks, so it must be
safe to apply.

Anyone in the future who will upgrade to make 3.81 will be affected by
this bug, btw.
Posted by Nobuyoshi Nakada (nobu)
on 22.01.2009 03:10
(Received via mailing list)
Hi,

At Tue, 20 Jan 2009 07:48:47 +0900,
Alexey Borzenkov wrote in [ruby-core:21448]:
> So this makes me really wonder how people are building Ruby with mingw and
> avoid this problem? Are you using something else beside msys? Would my
> patch break things for you then?

"Mingw port" means to compile with -mno-cygwin on Cygwin, for
us.
Posted by Alexey Borzenkov (snaury)
on 22.01.2009 07:59
(Received via mailing list)
On Thu, Jan 22, 2009 at 5:08 AM, Nobuyoshi Nakada <nobu@ruby-lang.org> 
wrote:
> Hi,
>
> At Tue, 20 Jan 2009 07:48:47 +0900,
> Alexey Borzenkov wrote in [ruby-core:21448]:
>> So this makes me really wonder how people are building Ruby with mingw and
>> avoid this problem? Are you using something else beside msys? Would my
>> patch break things for you then?
>
> "Mingw port" means to compile with -mno-cygwin on Cygwin, for
> us.

Hmm? And how do you call configure to do that?

Setting CC to "gcc -mno-cygwin" and CFLAGS/CPPFLAGS/LDFLAGS to
"-mno-cygwin" and then calling configure has no effect, they are just
completely ignored and I end up with a cygwin build. So what is the
official way to compile with -mno-cygwin?
Posted by Nobuyoshi Nakada (nobu)
on 22.01.2009 08:37
(Received via mailing list)
Hi,

At Thu, 22 Jan 2009 15:55:25 +0900,
Alexey Borzenkov wrote in [ruby-core:21512]:
> > "Mingw port" means to compile with -mno-cygwin on Cygwin, for
> > us.
> 
> Hmm? And how do you call configure to do that?

  ./configure CC="gcc -mno-cygwin"

> Setting CC to "gcc -mno-cygwin" and CFLAGS/CPPFLAGS/LDFLAGS to
> "-mno-cygwin" and then calling configure has no effect, they are just
> completely ignored and I end up with a cygwin build. So what is the
> official way to compile with -mno-cygwin?

No FLAGS are needed.
Posted by Alexey Borzenkov (snaury)
on 22.01.2009 21:25
(Received via mailing list)
On Thu, Jan 22, 2009 at 10:35 AM, Nobuyoshi Nakada <nobu@ruby-lang.org> 
wrote:
>> Hmm? And how do you call configure to do that?
>
>  ./configure CC="gcc -mno-cygwin"

Wow! Thanks a lot. :) Good to know, although cygwin bug (in that tries
to link with libraries in /usr/lib even under -mno-cygwin) is
annoying.

Still, my patch won't break cygwin compilation as build_os in case of
cygwin is cygwin and my path transformations only apply when build_os
is mingw32. :)