From pijnacker at dse.nl  Mon Apr  2 14:02:24 2007
From: pijnacker at dse.nl (Ronald Pijnacker)
Date: Mon, 2 Apr 2007 20:02:24 +0200
Subject: [Mkrf-users] Support for building on Windows
In-Reply-To: <20070330085006.GD11009@samsara.bebear.net>
References: <mailman.3.1175240856.11209.mkrf-users@rubyforge.org>
	<20070330081827.GI31850@best.ms.philips.com>
	<20070330085006.GD11009@samsara.bebear.net>
Message-ID: <20070402180224.GA6231@localhost>

Hi all,

This weekend I started out with building ruby-opengl on windows with mkrf.
Changing cc into #{CC} and adding " -DWIN32" to CFLAGS almost is enough
for building. The only thing left to decide is how to handle .o vs .obj files.
The object-file naming option in 'cl' is -Fo<object-file> which _needs_ to
be without spaces. To avoid messing around with variables for -Fo vs. -o one
option is to not use -o at all, however in that case 'cl' defaults to naming
the object file .obj. This requires that mkrf handles that correctly instead.

Any opinions on which way to go?

P.S. It would help to be able to discuss these issues on irc, instead of 
     via mail. Al, are you inclined to be available on e.g. #mkrf-dev ?

Groeten,

	Ronald.

From kevin.clark at gmail.com  Mon Apr  2 14:37:13 2007
From: kevin.clark at gmail.com (Kevin Clark)
Date: Mon, 2 Apr 2007 11:37:13 -0700
Subject: [Mkrf-users] Support for building on Windows
In-Reply-To: <20070402180224.GA6231@localhost>
References: <mailman.3.1175240856.11209.mkrf-users@rubyforge.org>
	<20070330081827.GI31850@best.ms.philips.com>
	<20070330085006.GD11009@samsara.bebear.net>
	<20070402180224.GA6231@localhost>
Message-ID: <f53e6950704021137g5a922e1fn32aa433928cf518c@mail.gmail.com>

I can be there. I should have time time coming up to work in mkrf again.

Kev

On 4/2/07, Ronald Pijnacker <pijnacker at dse.nl> wrote:
> Hi all,
>
> This weekend I started out with building ruby-opengl on windows with mkrf.
> Changing cc into #{CC} and adding " -DWIN32" to CFLAGS almost is enough
> for building. The only thing left to decide is how to handle .o vs .obj files.
> The object-file naming option in 'cl' is -Fo<object-file> which _needs_ to
> be without spaces. To avoid messing around with variables for -Fo vs. -o one
> option is to not use -o at all, however in that case 'cl' defaults to naming
> the object file .obj. This requires that mkrf handles that correctly instead.
>
> Any opinions on which way to go?
>
> P.S. It would help to be able to discuss these issues on irc, instead of
>      via mail. Al, are you inclined to be available on e.g. #mkrf-dev ?
>
> Groeten,
>
>         Ronald.
> _______________________________________________
> Mkrf-users mailing list
> Mkrf-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mkrf-users
>


-- 
Kevin Clark
http://glu.ttono.us

From hoanga at alum.rpi.edu  Mon Apr  2 15:51:14 2007
From: hoanga at alum.rpi.edu (Al Hoang)
Date: Tue, 3 Apr 2007 04:51:14 +0900
Subject: [Mkrf-users] Support for building on Windows
In-Reply-To: <20070402180224.GA6231@localhost>
References: <mailman.3.1175240856.11209.mkrf-users@rubyforge.org>
	<20070330081827.GI31850@best.ms.philips.com>
	<20070330085006.GD11009@samsara.bebear.net>
	<20070402180224.GA6231@localhost>
Message-ID: <35A449AE-4D03-44CB-95B7-FBFCCD5D8F29@alum.rpi.edu>

Hi,

On Apr 3, 2007, at 3:02 AM, Ronald Pijnacker wrote:

> Hi all,
>
> [snip]

> for building. The only thing left to decide is how to handle .o  
> vs .obj files.
> [snip]

> Any opinions on which way to go?

	I'm sure Kevin has his own ideas on this but my thoughts on this
lean towards mkrf should handle .obj files to minimize the number of
options one needs to inject to the compiler.

>
> P.S. It would help to be able to discuss these issues on irc,  
> instead of
>      via mail. Al, are you inclined to be available on e.g. #mkrf- 
> dev ?

	I'll try to start hanging around there from tomorrow morning (JST) to
help discuss these matters if it helps.

Alain

From kevin.clark at gmail.com  Mon Apr  2 15:54:39 2007
From: kevin.clark at gmail.com (Kevin Clark)
Date: Mon, 2 Apr 2007 12:54:39 -0700
Subject: [Mkrf-users] Support for building on Windows
In-Reply-To: <35A449AE-4D03-44CB-95B7-FBFCCD5D8F29@alum.rpi.edu>
References: <mailman.3.1175240856.11209.mkrf-users@rubyforge.org>
	<20070330081827.GI31850@best.ms.philips.com>
	<20070330085006.GD11009@samsara.bebear.net>
	<20070402180224.GA6231@localhost>
	<35A449AE-4D03-44CB-95B7-FBFCCD5D8F29@alum.rpi.edu>
Message-ID: <f53e6950704021254l48da6c73ma134289c15bc3205@mail.gmail.com>

Alain,
Ronald and I are chatting about it now. I agree, mkrf should handle
.obj files out of the box. I'll post the chatlog here (as long as
Ronald is ok with that) so you're up to date.

Kev

On 4/2/07, Al Hoang <hoanga at alum.rpi.edu> wrote:
> Hi,
>
> On Apr 3, 2007, at 3:02 AM, Ronald Pijnacker wrote:
>
> > Hi all,
> >
> > [snip]
>
> > for building. The only thing left to decide is how to handle .o
> > vs .obj files.
> > [snip]
>
> > Any opinions on which way to go?
>
>         I'm sure Kevin has his own ideas on this but my thoughts on this
> lean towards mkrf should handle .obj files to minimize the number of
> options one needs to inject to the compiler.
>
> >
> > P.S. It would help to be able to discuss these issues on irc,
> > instead of
> >      via mail. Al, are you inclined to be available on e.g. #mkrf-
> > dev ?
>
>         I'll try to start hanging around there from tomorrow morning (JST) to
> help discuss these matters if it helps.
>
> Alain
> _______________________________________________
> Mkrf-users mailing list
> Mkrf-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mkrf-users
>


-- 
Kevin Clark
http://glu.ttono.us

From kevin.clark at gmail.com  Mon Apr  2 16:00:19 2007
From: kevin.clark at gmail.com (Kevin Clark)
Date: Mon, 2 Apr 2007 13:00:19 -0700
Subject: [Mkrf-users] Support for building on Windows
In-Reply-To: <f53e6950704021254l48da6c73ma134289c15bc3205@mail.gmail.com>
References: <mailman.3.1175240856.11209.mkrf-users@rubyforge.org>
	<20070330081827.GI31850@best.ms.philips.com>
	<20070330085006.GD11009@samsara.bebear.net>
	<20070402180224.GA6231@localhost>
	<35A449AE-4D03-44CB-95B7-FBFCCD5D8F29@alum.rpi.edu>
	<f53e6950704021254l48da6c73ma134289c15bc3205@mail.gmail.com>
Message-ID: <f53e6950704021300u66bc3ca1r270930c7bb20f9aa@mail.gmail.com>

Oh, additionally, I think it might make sense to start up the ticket
tracker on rubyforge.

Any objections?

Kev

From kevin.clark at gmail.com  Mon Apr  2 16:08:10 2007
From: kevin.clark at gmail.com (Kevin Clark)
Date: Mon, 2 Apr 2007 13:08:10 -0700
Subject: [Mkrf-users] Support for building on Windows
In-Reply-To: <f53e6950704021300u66bc3ca1r270930c7bb20f9aa@mail.gmail.com>
References: <mailman.3.1175240856.11209.mkrf-users@rubyforge.org>
	<20070330081827.GI31850@best.ms.philips.com>
	<20070330085006.GD11009@samsara.bebear.net>
	<20070402180224.GA6231@localhost>
	<35A449AE-4D03-44CB-95B7-FBFCCD5D8F29@alum.rpi.edu>
	<f53e6950704021254l48da6c73ma134289c15bc3205@mail.gmail.com>
	<f53e6950704021300u66bc3ca1r270930c7bb20f9aa@mail.gmail.com>
Message-ID: <f53e6950704021308t6398adf9rd6182379d7d3c34@mail.gmail.com>

Here's the chatlog for the issue:

-- 
Kevin Clark
http://glu.ttono.us



================================

15:32 < rhp> I've been going about trying to generate a Rakefile from mkrf.
15:32 < rhp> After updating bits and pieces here and there, I got to a
situation where I the rakefile uses obj-files iso. o-files.
15:32 < rhp> xyz.lib iso. -lxyz
15:33 < rhp>  /libpath: iso. -L
15:33 < rhp> Now I'm stuck with the template in generator.rb. It seems
a bit crude to start all kinds of sections with if windows else
inthere.
15:33 < rhp> How would you go about that?
15:34 < kevinclark> hmmm
15:34 < kevinclark> Maybe it makes sense to have the rakefile writer
use a different template for windows?
15:34 < kevinclark> It's going to be largely different, isn't it?
15:35 < rhp> I edited the one for ruby-opengl by hand. It wasn't all
that different.
15:35 < rhp> The above stuff.
15:35 < rhp> + some small bits.
15:36 < kevinclark> do you mind pasting it for me so I can take a look?
15:36 < rhp> No, inside here?
15:36 < kevinclark> pastie.caboo.se
15:38 < kevinclark> a diff could work

[ED: The numbers here are the last part of a pastie url. 51210 ->
http://pastie.caboo.se/51210]

15:38 < rhp> 51210
15:38 < kevinclark> and maybe a second one for the rakefile?
15:38 < kevinclark> ah
15:38 < kevinclark> cool
15:38 < rhp> -DWIN32 seems to be necessary too.
15:38 < kevinclark> can I get the diff against the library?
15:39 < rhp> you mean my changes to mkrf?
15:39 < kevinclark> yup
15:39 < rhp> I'll past the svn diff
15:39 < kevinclark> sounds good
15:39 < kevinclark> if you set the type to diff, pastie will color
code it for me nicely
15:40 < rhp> 51212
15:40 < rhp> 51213 with colors
15:41 < rhp> Note that this does not yet generate a correct rakefile yet.
15:41 < rhp> There's still one -L in the template, for example.
15:41 < kevinclark> is 51210 vanilla from mkrf, or is that with modifications?
15:42 < kevinclark> mods, right?
15:43 < rhp> Also the link line needs an update. I noticed that ruby
is build with DLDFLAGS too. This one uses -implib and -def: and all.
15:43 < kevinclark> can you hack at the rakefile and get it to the
point where it works correctly? Then I can start adding options to the
generator dsl which generalize your changes
15:44 < rhp> 51210 is updated by hand to get ruby-opengl compiling.
That was my first goal. I'm trying to push things into the
mkrf_config.rb and mkrf from there to get it auto-generated.
15:44 < kevinclark> ok
...
15:47 < kevinclark> anyway, it sounds like you've got the right idea
about rolling things back in mkrf, do you want to try to write up a
patch? What sort of guidance can I give?
15:48 < kevinclark> a bunch of ifs in the template might be ugly, but
we could wrap those sections in methods which hid the ifs, so the
template was easier to understand
15:48 < rhp> Helping out with choices like: do we go for .o or .obj.
15:48 < rhp> That would probably help, yes.
15:48 < kevinclark> well, .o is the standard on *nix. I don't know
much about compiling extensions on windows, does it prefer .obj?
15:48 < kevinclark> I don't have a problem with setting good defaults
for the different OS
15:49 < rhp> 'cl -c' generates a .obj by default.
15:49 < rhp> We could generate .o, but then we would have to use
-Fo<object-file> where on unix one would use -o<space><object-file>
15:49 < rhp> This messes things up quite a bit.
15:49 < kevinclark> I'd go with the default then
15:50 < kevinclark> looks like it's stored in rbconfig (which you're
using), so it shouldn't be much of a hassle fetching it anyway, right?
15:50 < kevinclark> and feasably, we could provide access for changes
down the line
15:50 < rhp> On the other hand, if people would want to generate
a.obj  from b.c the default would not work.
15:50 < rhp> As you can see from the patch, i've got the .obj stuff
figured out, so that is sort-of in place.
15:50 < kevinclark> yup
15:50 < kevinclark> I'd say keep it
15:51 < kevinclark> and we'll provide a way to override
15:51 < kevinclark> I'd rather get it right for the 80% out of the box
15:51 < rhp> I was wondering what to do with the template, since I do
not feel like putting lots of 'if windows' in there.
15:51 < rhp> But I'll see if adding some helper methods will work enough.
15:52 < rhp> Any idea why -DWIN32 is not defined in rbconfig?
15:52 < kevinclark> Yeah, I like what you've done with
library_compile_string. That sort of thing feels like the template
would still be readable, but we could support windows without much
hassle
15:53 < rhp> Indead.
15:53 < kevinclark> I'm not sure. If you think it's always needed on
windows, I'd just add it to the flags by default on RUBY_PLATFORM =~
/mswin/
15:53 < rhp> Hm... indeed.
15:54 < rhp> I think the microsoft tools give errors in the standard
include headers if it is not defined. So that would imply that it is
needed always.
15:54 < rhp> That just leaves the -def:<def-file> problem. I think
ruby-opengl could be auto-generated after that.
15:55 < kevinclark> awesome
15:55 < rhp> Did you read the mail on the def-file problem?
15:56 < rhp> Any thoughts?
15:56 < kevinclark> I'm looking right now. Just a sec.
15:58 < kevinclark> I don't have a problem adding support for -def:.
Just make sure to note that it's WIN32 only in the rdoc
15:58 < kevinclark> and it just won't expand to anything on *nix
15:58 < rhp> Sure.
16:01 < kevinclark> Anything else I can help with? I think I'm going
to be heading to lunch in a few.
16:01 < kevinclark> I'm happy to idle in here if you have questions later.
16:01 < rhp> No, I'm switching attention to Dr. Who for a moment.
16:01 < rhp> In an hour I'll be off to bed.
16:02 < kevinclark> ok, sounds good
16:02 < rhp> I'll try to see what I can finish today, otherwise
tomorrow. If I have a working version I'll send the diffs to the list.
16:02 < kevinclark> sounds great. Thanks for looking into this stuff :)
16:03 < rhp> Have a nice lunch .
16:03 < kevinclark> mind if I post our conversation so Alain knows
what we talked about?
16:04 < rhp> No problem.

From hoanga at alum.rpi.edu  Tue Apr  3 12:22:33 2007
From: hoanga at alum.rpi.edu (Al Hoang)
Date: Wed, 4 Apr 2007 01:22:33 +0900
Subject: [Mkrf-users] Support for building on Windows
In-Reply-To: <f53e6950704021308t6398adf9rd6182379d7d3c34@mail.gmail.com>
References: <mailman.3.1175240856.11209.mkrf-users@rubyforge.org>
	<20070330081827.GI31850@best.ms.philips.com>
	<20070330085006.GD11009@samsara.bebear.net>
	<20070402180224.GA6231@localhost>
	<35A449AE-4D03-44CB-95B7-FBFCCD5D8F29@alum.rpi.edu>
	<f53e6950704021254l48da6c73ma134289c15bc3205@mail.gmail.com>
	<f53e6950704021300u66bc3ca1r270930c7bb20f9aa@mail.gmail.com>
	<f53e6950704021308t6398adf9rd6182379d7d3c34@mail.gmail.com>
Message-ID: <52DE1510-2435-4817-99E8-3D22F61C142C@alum.rpi.edu>

Hi,

On Apr 3, 2007, at 5:08 AM, Kevin Clark wrote:

> Here's the chatlog for the issue:
>

	Thanks for the chat log.  That helps a bit.  Sorry I wasn't on IRC  
today, I'll
try again tomorrow. I've been a bit swamped at work lately but it  
seems waiting
for when Ronald has a patch he feels ready with is where things are  
at right now.

	I tried creating an issue on the Tracker for this just so there is
something in the database.  It should be under ID 9787, Windows
Support for mkrf.

Cheers,
Alain

From pijnacker at dse.nl  Thu Apr  5 06:12:08 2007
From: pijnacker at dse.nl (Ronald Pijnacker)
Date: Thu, 5 Apr 2007 12:12:08 +0200
Subject: [Mkrf-users] Support for building on Windows
In-Reply-To: <52DE1510-2435-4817-99E8-3D22F61C142C@alum.rpi.edu>
References: <mailman.3.1175240856.11209.mkrf-users@rubyforge.org>
	<20070330081827.GI31850@best.ms.philips.com>
	<20070330085006.GD11009@samsara.bebear.net>
	<20070402180224.GA6231@localhost>
	<35A449AE-4D03-44CB-95B7-FBFCCD5D8F29@alum.rpi.edu>
	<f53e6950704021254l48da6c73ma134289c15bc3205@mail.gmail.com>
	<f53e6950704021300u66bc3ca1r270930c7bb20f9aa@mail.gmail.com>
	<f53e6950704021308t6398adf9rd6182379d7d3c34@mail.gmail.com>
	<52DE1510-2435-4817-99E8-3D22F61C142C@alum.rpi.edu>
Message-ID: <20070405101208.GI11974@best.ms.philips.com>

Hi all,

I've progressed to the point where the issues start being with the
ruby-opengl mkrf_config files instead of with mkrf itself.
I have some questions:

1. I think the idea is to include rbogl.o(bj) in both the gl.so and
   glu.so. However, including it in glu.so gives some problems because
   it expects the Init_gl symbol to be defined somewhere, which is not
   available in glu.so.

2. The Init_opengl symbol can be dropped, I think, since the name of the
   extension was changed into 'gl'.

   Just removing the Init_gl and Init_opengl from this file does not seem
   to give any problems (which I expected).

3. How bad would it be to include rbogl.c in both gl and glu Rakefiles?
   Although it would have to be built twice, it saves on Rakefile (in
   common/) which currently is not auto-generated.

4. How does libruby.so.x.y.z get sucked in on the other architectures?
   I seem to need to add this.

Groeten,

	Ronald.

From pijnacker at dse.nl  Thu Apr  5 07:15:58 2007
From: pijnacker at dse.nl (Ronald Pijnacker)
Date: Thu, 5 Apr 2007 13:15:58 +0200
Subject: [Mkrf-users] Support for building on Windows
In-Reply-To: <52DE1510-2435-4817-99E8-3D22F61C142C@alum.rpi.edu>
References: <mailman.3.1175240856.11209.mkrf-users@rubyforge.org>
	<20070330081827.GI31850@best.ms.philips.com>
	<20070330085006.GD11009@samsara.bebear.net>
	<20070402180224.GA6231@localhost>
	<35A449AE-4D03-44CB-95B7-FBFCCD5D8F29@alum.rpi.edu>
	<f53e6950704021254l48da6c73ma134289c15bc3205@mail.gmail.com>
	<f53e6950704021300u66bc3ca1r270930c7bb20f9aa@mail.gmail.com>
	<f53e6950704021308t6398adf9rd6182379d7d3c34@mail.gmail.com>
	<52DE1510-2435-4817-99E8-3D22F61C142C@alum.rpi.edu>
Message-ID: <20070405111557.GJ11974@best.ms.philips.com>

Hi all,

Please find attached the patch that makes compiling on windows a bit
easier.
Some things are a bit clumsy (hardcoded link lines etc.), but it is a
start.

Please have a look and let me know what you think.

Groeten,

	Ronald.
-------------- next part --------------
Index: lib/mkrf/generator.rb
===================================================================
--- lib/mkrf/generator.rb	(revision 55)
+++ lib/mkrf/generator.rb	(working copy)
@@ -153,24 +153,34 @@
     def defines_compile_string # :nodoc:
       @available.defines.collect {|define| "-D#{define}"}.join(' ')
     end
-    
+
+    def library_path(path) # :nodoc:
+      if RUBY_PLATFORM =~ /mswin/
+        "-libpath:#{path}"
+      else
+        "-L#{path}"
+      end
+    end
+
     def rakefile_contents # :nodoc:
+      objext = CONFIG['OBJEXT']
+
       <<-END_RAKEFILE
 # Generated by mkrf
 require 'rake/clean'
 
-CLEAN.include('*.o')
+CLEAN.include('*.#{objext}')
 CLOBBER.include('#{@extension_name}', 'mkrf.log')
 
 SRC = FileList[#{sources.join(',')}]
-OBJ = SRC.ext('o')
+OBJ = SRC.ext('#{objext}')
 CC = '#{@cc}'
 
 ADDITIONAL_OBJECTS = '#{objects}'
 
-LDSHARED = "#{CONFIG['LDSHARED']} #{ldshared}"
+LDSHARED = "#{@available.ldshared_string} #{ldshared}"
 
-LIBPATH =  "-L#{CONFIG['rubylibdir']} #{@available.library_paths_compile_string}"
+LIBPATH =  "#{library_path(CONFIG['libdir'])} #{@available.library_paths_compile_string}"
 
 INCLUDES = "#{@available.includes_compile_string}"
 
@@ -179,16 +189,17 @@
 CFLAGS = "#{cflags} #{defines_compile_string}"
 
 RUBYARCHDIR = "\#{ENV["RUBYARCHDIR"]}"
+LIBRUBYARG_SHARED = "#{CONFIG['LIBRUBYARG_SHARED']}"
 
 task :default => ['#{@extension_name}']
 
-rule '.o' => '.c' do |t|
-  sh "\#{CC} \#{CFLAGS} \#{INCLUDES} -c -o \#{t.name} \#{t.source}"
+rule '.#{objext}' => '.c' do |t|
+  sh "\#{CC} \#{CFLAGS} \#{INCLUDES} -c \#{t.source}"
 end
 
 desc "Build this extension"
 file '#{@extension_name}' => OBJ do
-  sh "\#{LDSHARED} \#{LIBPATH} -o #{@extension_name} \#{OBJ} \#{ADDITIONAL_OBJECTS} \#{LIBS}"
+  sh "\#{LDSHARED} \#{LIBPATH} #{@available.ld_outfile(@extension_name)} \#{OBJ} \#{ADDITIONAL_OBJECTS} \#{LIBS} \#{LIBRUBYARG_SHARED}"
 end
 
 desc "Install this extension"
Index: lib/mkrf/availability.rb
===================================================================
--- lib/mkrf/availability.rb	(revision 55)
+++ lib/mkrf/availability.rb	(working copy)
@@ -26,8 +26,7 @@
     # * <tt>:headers</tt> -- headers to load by default
     # * <tt>:compiler</tt> -- which compiler to use when determining availability
     # * <tt>:includes</tt> -- directories that should be searched for include files
-    def initialize(options = {})
-      
+    def initialize(options = {})      
       @loaded_libs = (options[:loaded_libs] || Config::CONFIG["LIBS"].gsub('-l', '').split).to_a
       @library_paths = (options[:library_paths] || "").to_a
       # Not sure what COMMON_HEADERS looks like when populated
@@ -74,6 +73,7 @@
     def has_library?(library, function = "main", *paths)
       logger.info "Checking for library: #{library}"
       return true if library_already_loaded?(library)
+      return true if RUBY_PLATFORM =~ /mswin/ # TODO: find a way on windows
       # Should this be only found_library? or a specialized version with
       # path searching?
       found_library?(library, function)
@@ -139,14 +139,38 @@
     
     # Returns a string of libraries formatted for compilation
     def library_compile_string
-      @loaded_libs.collect {|l| "-l#{l}"}.join(' ')
+      if RUBY_PLATFORM =~ /mswin/
+        @loaded_libs.join(' ')
+      else
+        @loaded_libs.collect {|l| "-l#{l}"}.join(' ')
+      end
     end
     
     # Returns a string of libraries directories formatted for compilation
     def library_paths_compile_string
-      @library_paths.collect {|l| "-L#{l}"}.join(' ')
+      if RUBY_PLATFORM =~ /mswin/
+        @library_paths.collect {|l| "/libpath:#{l}"}.join(' ')
+      else
+        @library_paths.collect {|l| "-L#{l}"}.join(' ')
+      end
     end
 
+    def ldshared_string
+      if RUBY_PLATFORM =~ /mswin/
+        "link -nologo -incremental:no -debug -opt:ref -opt:icf -dll"
+      else
+        CONFIG['LDSHARED']
+      end
+    end
+
+    def ld_outfile(filename) # :nodoc:
+      if RUBY_PLATFORM =~ /mswin/
+        "-out:#{filename}"
+      else
+        "-o #{filename}"
+      end
+    end
+
     # Returns a string of include directories formatted for compilation
     def includes_compile_string
       @includes.collect {|i| "-I#{i}"}.join(' ')
@@ -243,7 +267,7 @@
     def header_include_string
       @headers.collect {|header| "#include <#{header}>"}.join('\n')
     end
-    
+
     def link_command
       # This current implementation just splats the library_paths in
       # unconditionally.  Is this problematic?

From hoanga at alum.rpi.edu  Thu Apr  5 22:01:53 2007
From: hoanga at alum.rpi.edu (Alain Hoang)
Date: Fri, 06 Apr 2007 11:01:53 +0900
Subject: [Mkrf-users] Support for building on Windows
In-Reply-To: <20070405111557.GJ11974@best.ms.philips.com>
References: <mailman.3.1175240856.11209.mkrf-users@rubyforge.org>	<20070330081827.GI31850@best.ms.philips.com>	<20070330085006.GD11009@samsara.bebear.net>	<20070402180224.GA6231@localhost>	<35A449AE-4D03-44CB-95B7-FBFCCD5D8F29@alum.rpi.edu>	<f53e6950704021254l48da6c73ma134289c15bc3205@mail.gmail.com>	<f53e6950704021300u66bc3ca1r270930c7bb20f9aa@mail.gmail.com>	<f53e6950704021308t6398adf9rd6182379d7d3c34@mail.gmail.com>	<52DE1510-2435-4817-99E8-3D22F61C142C@alum.rpi.edu>
	<20070405111557.GJ11974@best.ms.philips.com>
Message-ID: <4615AA11.9040207@alum.rpi.edu>

Hi Ronald,

Ronald Pijnacker wrote:
> Hi all,
> 
> Please find attached the patch that makes compiling on windows a bit
> easier.
> Some things are a bit clumsy (hardcoded link lines etc.), but it is a
> start.
> 
> Please have a look and let me know what you think.
> 

	I've applied the patch and committed it into svn for now.
I'll try looking it over soon and see if I can think of anyplace to
clean it up.  If it looks good enough, I might just push out a new
gem (0.2.1) and see if it works as advertised.

Cheers,
Alain

From kevin.clark at gmail.com  Sun Apr  8 17:57:38 2007
From: kevin.clark at gmail.com (Kevin Clark)
Date: Sun, 8 Apr 2007 14:57:38 -0700
Subject: [Mkrf-users] Blogpost on Mkrf's missing features
Message-ID: <f53e6950704081457y1313e057m55073f8ad5b00cb4@mail.gmail.com>

This is great:

http://jrepp.com/2007/03/05/mkmf-versus-mkrf-round-1/

Anyone else run into blog posts or mailings about this stuff? I'm
going to make tickets for this stuff when I can, and maybe we can
start moving towards better compatability cross platform. Is anyone
else doing multi-platform builds?

-- 
Kevin Clark
http://glu.ttono.us

From kevin.clark at gmail.com  Tue Apr 10 02:28:14 2007
From: kevin.clark at gmail.com (Kevin Clark)
Date: Mon, 9 Apr 2007 23:28:14 -0700
Subject: [Mkrf-users] Building Cross Platform
Message-ID: <f53e6950704092328x7eb08302kfdbe2956bcfd3ab5@mail.gmail.com>

In regards to: http://jrepp.com/2007/03/05/mkmf-versus-mkrf-round-1/

---------- Forwarded message ----------
From: Jacob Repp <jacobrepp at gmail.com>
Date: Apr 8, 2007 5:15 PM
Subject:
To: kevin.clark at gmail.com


--- Comment:

Hi Jacob,

This is a great post. I've been actively seeking things like this for
a while. I'm going to make tickets for some of your issues as soon as
I can. If we get most of those resolved, would you be willing to test
the compile for us? Most of my issues with cross-compat is lack of
availability on my end.

--------

Hey Kevin, good to hear from you. I would be happy to test mkrf for
you on my project. I have mostly been working on windows but I'll be
porting to my mac this week sometime.

So if you need clarification on any of the problem I ran into let me
know. Regarding TRY_COMPILE.

The version of ruby and platform I'm using is:
ruby 1.8.4 (2005-12-24) [i386-mswin32]

I think I may have mis-represented the Config::CONFIG value. The value
that I think I was referring to at the time was:

TRY_LINK: cl -nologo -Feconftest $(INCFLAGS) -I$(hdrdir)  -MD -Zi -O2b2xg- -G6 $
(src) $(LOCAL_LIBS) oldnames.lib user32.lib advapi32.lib wsock32.lib  -link  $(L
IBPATH) -stack:0x2000000

I wrote up a simple script and included the output of my rbconfig settings.

On friday I released a version of my extension library if you have a
need to get a look at the source and existing extconf.rb I'm using
(it's really ugly ;) http://jrepp.com/rubycube/

Thanks! -j





-- 
Kevin Clark
http://glu.ttono.us
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dumpconfig.rb
Type: application/octet-stream
Size: 458 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mkrf-users/attachments/20070409/53ddffab/attachment.obj 
-------------- next part --------------
KEY: LIBRUBY
  msvcrt-ruby18.lib
KEY: prefix
  C:/Tools
KEY: sitedir
  C:/Tools/lib/ruby/site_ruby
KEY: DISTCLEANFILES
  vc*.pdb
KEY: COMMON_LIBS
  m
KEY: rubylibdir
  C:/Tools/lib/ruby/1.8
KEY: INSTALL_PROG
  copy > nul
KEY: target
  i386-pc-mswin32
KEY: AR
  lib -nologo
KEY: target_alias
  i386-mswin32
KEY: FFLAGS
  
KEY: RDOCTARGET
  install-nodoc
KEY: top_srcdir
  .
KEY: XCFLAGS
  -DRUBY_EXPORT -I. -I. -I./missing
KEY: RUBY_INSTALL_NAME
  ruby
KEY: LN_S
  
KEY: archdir
  C:/Tools/lib/ruby/1.8/i386-mswin32
KEY: srcdir
  C:.
KEY: LINK_SO
  cl -nologo -LD -Fe$(@) $(OBJS) oldnames.lib user32.lib advapi32.lib wsock32.lib  $(LOCAL_LIBS) -link -incremental:no -debug -opt:ref -opt:icf -dll $(LIBPATH) -def:$(DEFFILE) -implib:$(*F:.so=)-i386-mswin32.lib -pdb:$(*F:.so=)-i386-mswin32.pdb
KEY: MINIRUBY
  .\miniruby.exe
KEY: ARFLAGS
  -machine:x86 -out:
KEY: EXEEXT
  .exe
KEY: DLDLIBS
  
KEY: target_vendor
  pc
KEY: RUNRUBY
  .\ruby.exe "./runruby.rb" --extout=".ext" --
KEY: DESTDIR
  C:
KEY: sbindir
  C:/Tools/sbin
KEY: host_cpu
  i686
KEY: sitearch
  i386-msvcrt
KEY: DLEXT2
  dll
KEY: LIBS
  oldnames.lib user32.lib advapi32.lib wsock32.lib 
KEY: rubyw_install_name
  rubyw
KEY: EXTOUT
  .ext
KEY: arch
  i386-mswin32
KEY: MAJOR
  1
KEY: ruby_version
  1.8
KEY: CC
  cl -nologo
KEY: build_cpu
  i686
KEY: build_vendor
  pc
KEY: host_alias
  i686-mswin32
KEY: COMMON_HEADERS
  windows.h winsock.h
KEY: RANLIB
  
KEY: LDSHARED
  cl -nologo -LD
KEY: MINOR
  8
KEY: LIBOBJS
   acosh.obj crypt.obj erf.obj win32.obj
KEY: LIBRUBYARG_SHARED
  msvcrt-ruby18.lib
KEY: EXPORT_PREFIX
   
KEY: LIBRUBY_ALIASES
  
KEY: LDFLAGS
  
KEY: datadir
  C:/Tools/share
KEY: includedir
  C:/Tools/include
KEY: infodir
  C:/Tools/info
KEY: host_os
  mswin32
KEY: build
  i686-pc-mswin32
KEY: host
  i686-pc-mswin32
KEY: COMPILE_C
  cl -nologo -MD -Zi -O2b2xg- -G6  -c -Tc$(<:\=/)
KEY: INSTALL_DATA
  copy > nul
KEY: DLDFLAGS
  -link -incremental:no -debug -opt:ref -opt:icf -dll $(LIBPATH) -def:$(DEFFILE) -implib:$(*F:.so=)-i386-mswin32.lib -pdb:$(*F:.so=)-i386-mswin32.pdb
KEY: build_os
  mswin32
KEY: ruby_install_name
  ruby
KEY: DLEXT
  so
KEY: TEENY
  4
KEY: CPP
  cl
KEY: ALLOCA
  
KEY: sysconfdir
  C:/Tools/etc
KEY: exec_prefix
  C:/Tools
KEY: LIBRUBY_SO
  msvcrt-ruby18.dll
KEY: PATH_SEPARATOR
  ;
KEY: LIBEXT
  lib
KEY: mandir
  C:/Tools/man
KEY: libdir
  C:/Tools/lib
KEY: build_alias
  i686-mswin32
KEY: target_cpu
  i386
KEY: DEFAULT_KCODE
  
KEY: sharedstatedir
  C:/etc
KEY: RULE_SUBST
  {.;C:.;C:/Tools/lib/ruby/1.8/i386-mswin32;$(hdrdir)}%s
KEY: YACC
  byacc
KEY: host_vendor
  pc
KEY: TRY_LINK
  cl -nologo -Feconftest $(INCFLAGS) -I$(hdrdir)  -MD -Zi -O2b2xg- -G6 $(src) $(LOCAL_LIBS) oldnames.lib user32.lib advapi32.lib wsock32.lib  -link  $(LIBPATH) -stack:0x2000000
KEY: SOLIBS
  
KEY: configure_args
  --with-make-prog=nmake --enable-shared 
KEY: target_os
  mswin32
KEY: oldincludedir
  /usr/include
KEY: CP
  copy > nul
KEY: SET_MAKE
  
KEY: COMPILE_CXX
  $(CXX)   -c -Tp$(<:\=/)
KEY: RUBYW_INSTALL_NAME
  rubyw
KEY: LIBRUBYARG_STATIC
  msvcrt-ruby18-static.lib
KEY: LIBRUBYARG
  msvcrt-ruby18.lib
KEY: CXXFLAGS
  
KEY: EXTSTATIC
  
KEY: RPATHFLAG
  
KEY: SHELL
  $(COMSPEC)
KEY: STATIC
  
KEY: INSTALL
  copy > nul
KEY: COMPILE_RULES
  {C:.}.%s{}.%s: {C:/Tools/lib/ruby/1.8/i386-mswin32}.%s{}.%s: {$(hdrdir)}.%s{}.%s: .%s.%s:
KEY: sitearchdir
  C:/Tools/lib/ruby/site_ruby/1.8/i386-msvcrt
KEY: STRIP
  
KEY: ARCHFILE
  
KEY: LIBRUBY_DLDFLAGS
   -def:msvcrt-ruby18.def
KEY: OBJEXT
  obj
KEY: XLDFLAGS
  -stack:0x2000000
KEY: LIBRUBY_LDSHARED
  cl -nologo -LD
KEY: CCDLFLAGS
  
KEY: setup
  Setup
KEY: ENABLE_SHARED
  yes
KEY: CPPOUTFILE
  -P
KEY: topdir
  C:/Tools/lib/ruby/1.8/i386-mswin32
KEY: RUBY_SO_NAME
  msvcrt-ruby18
KEY: CFLAGS
  -MD -Zi -O2b2xg- -G6
KEY: localstatedir
  C:/var
KEY: LIBPATHFLAG
   -libpath:"%s"
KEY: bindir
  C:/Tools/bin
KEY: sitelibdir
  C:/Tools/lib/ruby/site_ruby/1.8
KEY: BUILD_FILE_SEPARATOR
  \
KEY: CPPFLAGS
  
KEY: libexecdir
  C:/Tools/libexec
KEY: OUTFLAG
  -Fe
KEY: LIBARG
  %s.lib
KEY: PREP
  miniruby.exe
KEY: LIBRUBY_A
  msvcrt-ruby18-static.lib
KEY: ARCH_FLAG
  

From hoanga at alum.rpi.edu  Sat Apr 14 07:44:08 2007
From: hoanga at alum.rpi.edu (Alain Hoang)
Date: Sat, 14 Apr 2007 20:44:08 +0900
Subject: [Mkrf-users] [ANN] Mkrf-0.2.1 Released
Message-ID: <4620BE88.9080000@alum.rpi.edu>

Hello all,

1. I would like to announce the new release of mkrf.  Included patches 
to enable preliminary Windows support (Thanks to Ronald).


If you're interested in the project you may like to join the mailing
list (http://rubyforge.org/mailman/listinfo/mkrf-users).

= What is mkrf?

mkrf was created as a Google Summer of Code project and is used for
creating Rakefiles to build C extensions to Ruby. mkrf is intended as
a replacement for mkmf.

Major goals of mkrf include a simple interface with proper
documentation and easy code reuse for related projects like RubyGems.



Cheers,
Alain