From kevin.clark at gmail.com Fri Sep 1 13:37:22 2006 From: kevin.clark at gmail.com (Kevin Clark) Date: Fri, 1 Sep 2006 10:37:22 -0700 Subject: [Mkrf-users] Welcome to the list and bugfixes Message-ID: Hi guys, Apparently even though I setup the list I wasn't automatically added to it. That's been fixed now. I'm planning a release for next week that fixes Robin's problems with C++ extensions and I'll add in John's fix for the RDoc as well. I plan to open up CFLAGS and friends through accessors so you can all tweak them to your heart's delight. Anything else that should be in the next release? -- Kevin Clark http://glu.ttono.us From jmg3000 at gmail.com Fri Sep 1 14:11:58 2006 From: jmg3000 at gmail.com (John Gabriele) Date: Fri, 1 Sep 2006 14:11:58 -0400 Subject: [Mkrf-users] Welcome to the list and bugfixes In-Reply-To: References: Message-ID: <65e0bb520609011111n2b05258fwd811abc542cdf864@mail.gmail.com> On 9/1/06, Kevin Clark wrote: > Hi guys, > Apparently even though I setup the list I wasn't automatically added > to it. That's been fixed now. I'm planning a release for next week > that fixes Robin's problems with C++ extensions and I'll add in John's > fix for the RDoc as well. I plan to open up CFLAGS and friends through > accessors so you can all tweak them to your heart's delight. Sounds great. Thank you! > Anything > else that should be in the next release? Although I understand that you'll probably write a tutorial for mkrf at some point, I'm hoping you'll put just a little more tutorial content into the README. For example, I'm working on a project that consists of 2 somewhat related extension modules that wrap some C libs. Currently, with mkmf, one of the modules wraps two libs, the other wraps one lib. Could you please add an "== Example" section after the "== Basic Usage" section that would contain a paragraph or two about how many Generator objects one would need in the general case like this? Also, how many Availability objects? Hm... does each .so file that gets built need its own extconf.rb? A recommendation about directory layout would be nice also (i.e., "Create an ext directory in your project directory. Inside ext, make subdirectories for each lib you plan on wrapping" -- or whatever is customary (I don't know what that custom is.)). That sort of general info for projects that are a little bit more complicated than the simplest "one lib, one module" cases would be *extremely* helpful, IMO, and might only take up a couple of paragraphs. Thanks, :) ---John From robin at nibor.org Fri Sep 1 17:23:25 2006 From: robin at nibor.org (Robin Stocker) Date: Fri, 01 Sep 2006 23:23:25 +0200 Subject: [Mkrf-users] Welcome to the list and bugfixes In-Reply-To: References: Message-ID: <44F8A4CD.1090702@nibor.org> Kevin Clark wrote: > Hi guys, > Apparently even though I setup the list I wasn't automatically added > to it. That's been fixed now. Welcome to the list then ;) > I'm planning a release for next week > that fixes Robin's problems with C++ extensions and I'll add in John's > fix for the RDoc as well. I plan to open up CFLAGS and friends through > accessors so you can all tweak them to your heart's delight. Anything > else that should be in the next release? Thanks! I just have a cosmetic suggestion. The last time I checked, the generated Rakefile would come out indented by 4 or 6 spaces, which looks a bit odd. Could you change that to no indenting? Another question: How do you intend the generator scripts to be named? Should they also be called "extconf.rb" or do you have a new name to distinguish mkrf files from mkmf ones? Thanks, Robin From kevin.clark at gmail.com Fri Sep 1 17:54:14 2006 From: kevin.clark at gmail.com (Kevin Clark) Date: Fri, 1 Sep 2006 14:54:14 -0700 Subject: [Mkrf-users] Fwd: Welcome to the list and bugfixes In-Reply-To: References: <44F8A4CD.1090702@nibor.org> Message-ID: This apparently didn't go to the list. I'll see if there's a setting for reply-to that I've missed. ---------- Forwarded message ---------- From: Kevin Clark Date: Sep 1, 2006 2:36 PM Subject: Re: [Mkrf-users] Welcome to the list and bugfixes To: Robin Stocker Robin, The indentation is fixed in svn. It'll be in the next release. I haven't decided how the generator scripts should be named. Do the people on the list have a preference? Kev On 9/1/06, Robin Stocker wrote: > Kevin Clark wrote: > > Hi guys, > > Apparently even though I setup the list I wasn't automatically added > > to it. That's been fixed now. > > Welcome to the list then ;) > > > I'm planning a release for next week > > that fixes Robin's problems with C++ extensions and I'll add in John's > > fix for the RDoc as well. I plan to open up CFLAGS and friends through > > accessors so you can all tweak them to your heart's delight. Anything > > else that should be in the next release? > > Thanks! I just have a cosmetic suggestion. The last time I checked, the > generated Rakefile would come out indented by 4 or 6 spaces, which looks > a bit odd. Could you change that to no indenting? > > Another question: How do you intend the generator scripts to be named? > Should they also be called "extconf.rb" or do you have a new name to > distinguish mkrf files from mkmf ones? > > Thanks, > Robin > _______________________________________________ > Mkrf-users mailing list > Mkrf-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mkrf-users > -- Kevin Clark http://glu.ttono.us -- Kevin Clark http://glu.ttono.us From jmg3000 at gmail.com Sat Sep 2 01:29:34 2006 From: jmg3000 at gmail.com (John Gabriele) Date: Sat, 2 Sep 2006 01:29:34 -0400 Subject: [Mkrf-users] Fwd: Welcome to the list and bugfixes In-Reply-To: References: <44F8A4CD.1090702@nibor.org> Message-ID: <65e0bb520609012229k724d310doac5caa2775f7d5e@mail.gmail.com> On 9/1/06, Kevin Clark wrote: > This apparently didn't go to the list. I'll see if there's a setting > for reply-to that I've missed. By default, you have to hit "Reply to all" to reply to the list. This is the default setting for RubyForge ML's and they strongly recommend keeping it that way. The ruby-talk list seems to do it differently such that you can just hit "Reply" to get it addressed to the list. > Robin S. wrote: > > Another question: How do you intend the generator scripts to be named? > > Should they also be called "extconf.rb" or do you have a new name to > > distinguish mkrf files from mkmf ones? > > [snip] > > I haven't decided how the generator scripts should be named. Do the > people on the list have a preference? IMO, the user shouldn't have to care what underlying module the extension module author is using, and so should be presented with the same old extconf.rb filename that they're used to seeing. ---John From jmg3000 at gmail.com Mon Sep 4 01:54:13 2006 From: jmg3000 at gmail.com (John Gabriele) Date: Mon, 4 Sep 2006 01:54:13 -0400 Subject: [Mkrf-users] questions about FileList, LIBPATH, -lruby, and adding in a .o file Message-ID: <65e0bb520609032254w7d0f0998jab38ce07ee49d4df@mail.gmail.com> Hi, I'm having a few issues with mkrf that I'm hoping someone might be able to help clear up. I created a simple extconf.rb file containing: require 'rubygems' require 'mkrf' Mkrf::Generator.new( 'foo' ) and it created a Rakefile with stuff such as: 1. SRC = FileList['lib/*.c'] I don't have a "lib" directory inside my project's ext directory. Does mkrf think I should have one? All my source is just sitting right in the project's ext directory. 2. LIBPATH = '-L"/usr/local/lib"' I never told mkrf anything about /usr/local/lib. Why is it being listed there? Does it think that's where Ruby is installed? How do I tell mkrf that my Ruby is actually installed in /opt/ruby-1.8.4? Hm... Seems like something it should already know... 3. LIBS = "-lruby -ldl" I don't have a libruby.so. I've only got /opt/ruby-1.8.4/lib/libruby-static.a. I installed from source into /opt/ruby-1.8.4 using the usual standard procedure. 4. How do I specify that I want an extra object linked in to my extension module? I want to add ../common/bar.o at the link stage. Hm... maybe g.add_source( '../common/*.o' )? Seems like there should be an "add_objects" method maybe... 5. How do I know what build targets I have available to me, for when I run the rake command? I guessed one already: "rake clean"... :) Thanks very much! (Kev, sorry for the duplicate message. After I emailed you, I realized that the list might benefit from the answers to the above questions, so I posted to the list.) ---John From kevin.clark at gmail.com Mon Sep 4 19:34:39 2006 From: kevin.clark at gmail.com (Kevin Clark) Date: Mon, 4 Sep 2006 16:34:39 -0700 Subject: [Mkrf-users] Fwd: questions about FileList, LIBPATH, -lruby, and adding in a .o file In-Reply-To: References: <65e0bb520609032254w7d0f0998jab38ce07ee49d4df@mail.gmail.com> Message-ID: Sorry, this didn't get sent to the list again. I'll tweak those settings ASAP. Also, item 3 is now fixed in trunk. I'll take care of the other bug soonish. ---------- Forwarded message ---------- From: Kevin Clark Date: Sep 4, 2006 4:04 PM Subject: Re: [Mkrf-users] questions about FileList, LIBPATH, -lruby, and adding in a .o file To: John Gabriele Hi John, > I'm having a few issues with mkrf that I'm hoping someone might be > able to help clear up. I created a simple extconf.rb file containing: > > require 'rubygems' > require 'mkrf' > Mkrf::Generator.new( 'foo' ) > > and it created a Rakefile with stuff such as: > > 1. > SRC = FileList['lib/*.c'] > > I don't have a "lib" directory inside my project's ext directory. Does mkrf > think I should have one? All my source is just sitting right in the > project's ext directory. By default mkrf assumes you're compiling .c files in the lib/ directory. If that isn't the case you can override it using the second argument to Mkrf::Generator.new. For example, with libxml the call looks like this: Mkrf::Generator.new('libxml_so', '*.c') do |g| It just grabs .c files in the local directory. This is probably what you want. > 2. > LIBPATH = '-L"/usr/local/lib"' > > I never told mkrf anything about /usr/local/lib. Why is it being > listed there? Does it think that's where Ruby is installed? How do I > tell mkrf that my Ruby is actually installed in /opt/ruby-1.8.4? Hm... Seems > like something it should already know... You're right, that's residual from incorrect assumptions early on. It's a bug, I'll fix it. Give me a couple days and I'll see if I can't get a decent bug tracking solution up somewhere. I'll post to the list. > 3. > LIBS = "-lruby -ldl" > > I don't have a libruby.so. I've only got > /opt/ruby-1.8.4/lib/libruby-static.a. I installed from source into > /opt/ruby-1.8.4 using the usual standard procedure. Those are default libs in the Availability class. You can override the loaded_libs in the Availability constructor but I don't seem to have given access in the Generator controller. This is a bug. I'll fix it ;) > 4. How do I specify that I want an extra object linked in to my > extension module? I want to add ../common/bar.o at the link stage. Hm... maybe > g.add_source( '../common/*.o' )? Seems like there should be an > "add_objects" method maybe... That sounds reasonable. > 5. How do I know what build targets I have available to me, for when I > run the rake command? I guessed one already: "rake clean"... :) `rake -T` should tell you this. -- Kevin Clark http://glu.ttono.us -- Kevin Clark http://glu.ttono.us From jmg3000 at gmail.com Mon Sep 4 22:53:14 2006 From: jmg3000 at gmail.com (John Gabriele) Date: Mon, 4 Sep 2006 22:53:14 -0400 Subject: [Mkrf-users] Fwd: questions about FileList, LIBPATH, -lruby, and adding in a .o file In-Reply-To: References: <65e0bb520609032254w7d0f0998jab38ce07ee49d4df@mail.gmail.com> Message-ID: <65e0bb520609041953x444cf8b9wce75e0af50f4b277@mail.gmail.com> On 9/4/06, Kevin Clark wrote: > > Hi John, > > > I'm having a few issues with mkrf that I'm hoping someone might be > > able to help clear up. I created a simple extconf.rb file containing: > > > > require 'rubygems' > > require 'mkrf' > > Mkrf::Generator.new( 'foo' ) > > > > and it created a Rakefile with stuff such as: > > > > 1. > > SRC = FileList['lib/*.c'] > > > > I don't have a "lib" directory inside my project's ext directory. Does mkrf > > think I should have one? All my source is just sitting right in the > > project's ext directory. > > By default mkrf assumes you're compiling .c files in the lib/ > directory. If that isn't the case you can override it using the second > argument to Mkrf::Generator.new. > > For example, with libxml the call looks like this: > > Mkrf::Generator.new('libxml_so', '*.c') do |g| > > It just grabs .c files in the local directory. This is probably what you want. Ah... I see. Then, by default, is the user expected to run the my_proj/ext/extconf.rb file directly from the my_proj directory, rather than from my_proj/ext? I'm guessing, judging from the default, that it's assumed that it's more customary to keep your C files in my_proj/lib rather than my_proj/ext. But the docs show the example code as: Mkrf::Generator.new('libxml', '*.c') do |g| ... Just curious, why did you choose to have Generator.new use 'lib/*.c' as the default rather than '*.c'? > > > 2. > > LIBPATH = '-L"/usr/local/lib"' > > > > I never told mkrf anything about /usr/local/lib. Why is it being > > listed there? Does it think that's where Ruby is installed? How do I > > tell mkrf that my Ruby is actually installed in /opt/ruby-1.8.4? Hm... Seems > > like something it should already know... > > You're right, that's residual from incorrect assumptions early on. > It's a bug, I'll fix it. Give me a couple days and I'll see if I can't > get a decent bug tracking solution up somewhere. I'll post to the > list. Great. Thanks! It would be great if, for now, you could keep us posted here on the list as the fixes come in. :) > > 3. > > LIBS = "-lruby -ldl" > > > > I don't have a libruby.so. I've only got > > /opt/ruby-1.8.4/lib/libruby-static.a. I installed from source into > > /opt/ruby-1.8.4 using the usual standard procedure. > > Those are default libs in the Availability class. You can override the > loaded_libs in the Availability constructor but I don't seem to have > given access in the Generator controller. This is a bug. I'll fix it > ;) And Kev also wrote: > Also, item 3 is now fixed in trunk. [snip] After installing from svn, I now get: LIBPATH = '-L"/usr/local/lib"' #... LIBS = "" in my Rakefile. Then running "rake" builds my extension, and I'm able to "require" it without error in irb. :) Say, by the way, do you have a recommended install procedure for installing from a clean svn checkout? I just manually copied the contents of the lib directory to my .../lib/ruby/site_ruby/1.8 directory. > > > 4. How do I specify that I want an extra object linked in to my > > extension module? I want to add ../common/bar.o at the link stage. Hm... maybe > > g.add_source( '../common/*.o' )? Seems like there should be an > > "add_objects" method maybe... > > That sounds reasonable. Currently, is there a way to specify in extconf.rb that I want that extra .o file added to LIBS in the Rakefile? > > > 5. How do I know what build targets I have available to me, for when I > > run the rake command? I guessed one already: "rake clean"... :) > > `rake -T` should tell you this. Whoops. :) Thanks. ---John From jmg3000 at gmail.com Tue Sep 5 10:36:28 2006 From: jmg3000 at gmail.com (John Gabriele) Date: Tue, 5 Sep 2006 10:36:28 -0400 Subject: [Mkrf-users] Fwd: questions about FileList, LIBPATH, -lruby, and adding in a .o file In-Reply-To: <65e0bb520609041953x444cf8b9wce75e0af50f4b277@mail.gmail.com> References: <65e0bb520609032254w7d0f0998jab38ce07ee49d4df@mail.gmail.com> <65e0bb520609041953x444cf8b9wce75e0af50f4b277@mail.gmail.com> Message-ID: <65e0bb520609050736m7d10b3c8q8ecc45b0cbe885e2@mail.gmail.com> On 9/4/06, John Gabriele wrote: > On 9/4/06, Kevin Clark wrote: > > > > Hi John, > > > > > I'm having a few issues with mkrf that I'm hoping someone might be > > > able to help clear up. I created a simple extconf.rb file containing: > > > > > > require 'rubygems' > > > require 'mkrf' > > > Mkrf::Generator.new( 'foo' ) > > > > > > and it created a Rakefile with stuff such as: > > > > > > 1. > > > SRC = FileList['lib/*.c'] > > > > > > I don't have a "lib" directory inside my project's ext directory. Does mkrf > > > think I should have one? All my source is just sitting right in the > > > project's ext directory. > > > > By default mkrf assumes you're compiling .c files in the lib/ > > directory. If that isn't the case you can override it using the second > > argument to Mkrf::Generator.new. > > > > For example, with libxml the call looks like this: > > > > Mkrf::Generator.new('libxml_so', '*.c') do |g| > > > > It just grabs .c files in the local directory. This is probably what you want. > > Ah... I see. > > Then, by default, is the user expected to run the > my_proj/ext/extconf.rb file directly from the my_proj directory, > rather than from my_proj/ext? > > I'm guessing, judging from the default, that it's assumed that it's > more customary to keep your C files in my_proj/lib rather than > my_proj/ext. But the docs show the example code as: > > Mkrf::Generator.new('libxml', '*.c') do |g| ... > > Just curious, why did you choose to have Generator.new use 'lib/*.c' > as the default rather than '*.c'? By the way, poking around, it looks to me that most folks building extension modules keep their source in my_proj/ext/mod_name, and then after the extension module is built, the .so file ends up in my_proj/lib. Has anyone else seen a convention other than this? Thanks, ---John From kevin.clark at gmail.com Sun Sep 10 18:01:49 2006 From: kevin.clark at gmail.com (Kevin Clark) Date: Sun, 10 Sep 2006 15:01:49 -0700 Subject: [Mkrf-users] SVN Updates (preparing for prerelease) Message-ID: Hi guys, Here's the interesting things in the changelog from today: * [FIXED] Correct defaults in Availability. [29] * [NEW] Using rubylibdir from rbconfig for library path. [29] * [NEW] Availability options go straight to availability without generator modification. [29] * [NEW] CFLAGS and LDSHARED now accessible through .cflags and .ldshared. [29] If you'd like to play, feel free to tell me what I'm still missing. Tonight I should have updates for c++ compilations as well, so be on the look out. I expect to put out a pre-release gem sometime tonight to prepare for a release early this week. -- Kevin Clark http://glu.ttono.us From jmg3000 at gmail.com Mon Sep 11 01:36:50 2006 From: jmg3000 at gmail.com (John Gabriele) Date: Mon, 11 Sep 2006 01:36:50 -0400 Subject: [Mkrf-users] SVN Updates (preparing for prerelease) In-Reply-To: References: Message-ID: <65e0bb520609102236o6248be41h1205648710c5efa9@mail.gmail.com> On 9/10/06, Kevin Clark wrote: > Hi guys, > Here's the interesting things in the changelog from today: > > * [FIXED] Correct defaults in Availability. [29] > * [NEW] Using rubylibdir from rbconfig for library path. [29] > * [NEW] Availability options go straight to availability without > generator modification. [29] > * [NEW] CFLAGS and LDSHARED now accessible through .cflags and .ldshared. [29] > > If you'd like to play, feel free to tell me what I'm still missing. Hi Kev, Thanks for the update. :) Not sure if anything's missing, but I've got a question or two. My extconf.rb is: | | require 'mkrf' | | Mkrf::Generator.new( 'foo', '*.c' ) do |g| | g.ldshared << ' ../common/garbonzo.o' | end | Note, there was no g.obj attribute, otherwise I'd have appended to that instead of g.ldshared. What do you think of adding an @obj to Generator like you did with @ldshared? Also, it seems customary to me that the .c files for an extension usually live right in the ext directory (or subdirs therein). Not sure why the default for Generator.new is to look for them in lib. I asked about it in a previous message to the list but didn't hear anything on it. Anyway, at the end of the resulting rakefile (note, the complete rakefile is pasted in at the end of this email), I've got: | | rule '.so' => '.o' do |t| | sh "#{LDSHARED} #{LIBPATH} -o #{OBJ} #{LOCAL_LIBS} #{LIBS}" | end | | desc "Build this extension" | file 'foo.so' => OBJ do | sh "#{LDSHARED} #{LIBPATH} -o foo.so #{OBJ} #{LIBS}" | end My extension is just one .so file, but there seems to be two ways specified here on how to get it: the rule and then the action in the file task after it called "foo.so". Aren't all extensions just .so files? It seems to me that the ".so" rule might be unnecessary and actually ignored by rake. (BTW, in that ".so" rule above, it says "-o #{OBJ}", but OBJ is an array. If that rule were kept, shouldn't there be a #{t.name} squeezed in after the "-o"?) Another question I have is, what's that LOCAL_LIBS variable doing in there? It only appears in that one spot in the Rakefile and isn't set to anything. The last thing I notice is, in Generator#rakefile_contents, should SRC = FileList[#{sources.join(',')}] instead be SRC = FileList[#{@sources.join(',')}] ? BTW, for reference, here's the complete rakefile that was generated: === snip === require 'rake/clean' CLEAN.include('*.o') CLOBBER.include('foo.so', 'mkrf.log') SRC = FileList['*.c'] OBJ = SRC.ext('o') CC = "gcc" LDSHARED = "gcc -shared ../common/garbonzo.o" LIBPATH = '-L"/opt/ruby-1.8.4/lib/ruby/1.8"' INCLUDES = "-I/opt/ruby-1.8.4/include -I/opt/ruby-1.8.4/lib/ruby/1.8/i686-linux -I/opt/ruby-1.8.4/lib/ruby/site_ruby/1.8 -I." LIBS = "-ldl -lcrypt -lm" CFLAGS = " -fPIC -g -O2 " task :default => ['foo.so'] rule '.o' => '.c' do |t| sh "#{CC} #{CFLAGS} #{INCLUDES} -c -o #{t.name} #{t.source}" end rule '.so' => '.o' do |t| sh "#{LDSHARED} #{LIBPATH} -o #{OBJ} #{LOCAL_LIBS} #{LIBS}" end desc "Build this extension" file 'foo.so' => OBJ do sh "#{LDSHARED} #{LIBPATH} -o foo.so #{OBJ} #{LIBS}" end === /snip === Thanks, ---John From kevin.clark at gmail.com Tue Sep 12 15:10:52 2006 From: kevin.clark at gmail.com (Kevin Clark) Date: Tue, 12 Sep 2006 12:10:52 -0700 Subject: [Mkrf-users] Fwd: SVN Updates (preparing for prerelease) In-Reply-To: References: <65e0bb520609102236o6248be41h1205648710c5efa9@mail.gmail.com> Message-ID: Forwarding to list. Dang it, I'm going to rubyforge to fix this option _right now_. ---------- Forwarded message ---------- From: Kevin Clark Date: Sep 12, 2006 12:08 PM Subject: Re: [Mkrf-users] SVN Updates (preparing for prerelease) To: John Gabriele Hi John, > My extconf.rb is: > | > | require 'mkrf' > | > | Mkrf::Generator.new( 'foo', '*.c' ) do |g| > | g.ldshared << ' ../common/garbonzo.o' > | end > | > > Note, there was no g.obj attribute, otherwise I'd have appended to > that instead of g.ldshared. What do you think of adding an @obj to > Generator like you did with @ldshared? That sounds reasonable. > Also, it seems customary to me that the .c files for an extension > usually live right in the ext directory (or subdirs therein). Not sure > why the default for Generator.new is to look for them in lib. I asked > about it in a previous message to the list but didn't hear anything on > it. People have classically put their mkmf extconfs directly in the extensions directory, but I thought that was ugly and we might want to encourage a directory structure. If people disagree I can change the default, but since it's so each to change in the 'new' call I'm inclined not to. > Anyway, at the end of the resulting rakefile (note, the complete > rakefile is pasted in at the end of this email), I've got: > | > | rule '.so' => '.o' do |t| > | sh "#{LDSHARED} #{LIBPATH} -o #{OBJ} #{LOCAL_LIBS} #{LIBS}" > | end > | > | desc "Build this extension" > | file 'foo.so' => OBJ do > | sh "#{LDSHARED} #{LIBPATH} -o foo.so #{OBJ} #{LIBS}" > | end > > My extension is just one .so file, but there seems to be two ways > specified here on how to get it: the rule and then the action in the > file task after it called "foo.so". Aren't all extensions just .so > files? It seems to me that the ".so" rule might be unnecessary and > actually ignored by rake. I think that was residual from a previous version. I'll remove it for the release. > (BTW, in that ".so" rule above, it says "-o #{OBJ}", but OBJ is an > array. If that rule were kept, shouldn't there be a #{t.name} squeezed > in after the "-o"?) Nope. Because OBJ comes from SRC.ext (a rake method) it's ready to be shoved in a compile string. If you find it doesn't work, tell me. > Another question I have is, what's that LOCAL_LIBS variable doing in > there? It only appears in that one spot in the Rakefile and isn't set > to anything. This too is residual and is removed with the old rule. > The last thing I notice is, in Generator#rakefile_contents, should > > SRC = FileList[#{sources.join(',')}] > > instead be > > SRC = FileList[#{@sources.join(',')}] Nope. If you notice in generator.rb, sources is an accessor which returns the sources as single quoted strings (which are then joined). -- Kevin Clark http://glu.ttono.us -- Kevin Clark http://glu.ttono.us From jmg3000 at gmail.com Wed Sep 13 03:48:28 2006 From: jmg3000 at gmail.com (John Gabriele) Date: Wed, 13 Sep 2006 03:48:28 -0400 Subject: [Mkrf-users] Fwd: SVN Updates (preparing for prerelease) In-Reply-To: References: <65e0bb520609102236o6248be41h1205648710c5efa9@mail.gmail.com> Message-ID: <65e0bb520609130048i204af585rd51a80753a4eae83@mail.gmail.com> On 9/12/06, Kevin Clark wrote: > > Hi John, Hi Kev, Sorry for the late reply. The DVD for "The Office" season 2 came out today, so I've been AFK for a while. :) > > My extconf.rb is: > > | > > | require 'mkrf' > > | > > | Mkrf::Generator.new( 'foo', '*.c' ) do |g| > > | g.ldshared << ' ../common/garbonzo.o' > > | end > > | > > > > Note, there was no g.obj attribute, otherwise I'd have appended to > > that instead of g.ldshared. What do you think of adding an @obj to > > Generator like you did with @ldshared? > > That sounds reasonable. Cool. How about this: Index: generator.rb =================================================================== --- generator.rb (revision 30) +++ generator.rb (working copy) @@ -33,7 +33,9 @@ attr_accessor :additional_code # Any extra code to be added to the Rakefile as a string - attr_accessor :ldshared, :cflags + # You may append to these attributes directly in your Generator.new block + # like so: g.obj << ' ../common/foo.o' + attr_accessor :ldshared, :objs, :cflags # Create a new generator which will write a new +Rakefile+ to the local # filesystem. @@ -48,6 +50,7 @@ @defines = [] @ldshared = CONFIG['LDSHARED'] + @objs = '' @cflags = "#{CONFIG['CCDLFLAGS']} #{CONFIG['CFLAGS']} #{CONFIG['ARCH_FLAG']}" yield self if block_given? @@ -137,7 +140,8 @@ CC = "gcc" LDSHARED = "#{@ldshared}" -LIBPATH = '-L"#{CONFIG['rubylibdir']}"' +OBJS = "#{@objs}" +LIBPATH = '-L"#{CONFIG['rubylibdir']}"' INCLUDES = "#{@available.includes_compile_string}" @@ -151,17 +155,18 @@ sh "\#{CC} \#{CFLAGS} \#{INCLUDES} -c -o \#{t.name} \#{t.source}" end +# Didn't add \#{OBJS} here since this rule is going away. XXX rule '.so' => '.o' do |t| sh "\#{LDSHARED} \#{LIBPATH} -o \#{OBJ} \#{LOCAL_LIBS} \#{LIBS}" end desc "Build this extension" file '#{@extension_name}' => OBJ do - sh "\#{LDSHARED} \#{LIBPATH} -o #{@extension_name} \#{OBJ} \#{LIBS}" + sh "\#{LDSHARED} \#{LIBPATH} -o #{@extension_name} \#{OBJ} \#{OBJS} \#{LIBS}" end #{additional_code} END_RAKEFILE end end -end \ No newline at end of file +end (see also attached as a patch file) > > Also, it seems customary to me that the .c files for an extension > > usually live right in the ext directory (or subdirs therein). Not sure > > why the default for Generator.new is to look for them in lib. I asked > > about it in a previous message to the list but didn't hear anything on > > it. > > People have classically put their mkmf extconfs directly in the > extensions directory, but I thought that was ugly and we might want to > encourage a directory structure. Hm. But, the directory structure as I understand it is: * ext -- put your extconf.rb and .c files in here * lib -- put stuff in here that you want your users to be able to 'require' (i.e., .rb files and .so files). Is that what's been customary up 'til now? It's what the PickAxe seems to show. > If people disagree I can change the > default, but since it's so each to change in the 'new' call I'm > inclined not to. I think mkrf will set an example for folks new to writing extension modules, so, IMO, the defaults should reflect what's most customary. > > Anyway, at the end of the resulting rakefile (note, the complete > > rakefile is pasted in at the end of this email), I've got: > > | > > | rule '.so' => '.o' do |t| > > | sh "#{LDSHARED} #{LIBPATH} -o #{OBJ} #{LOCAL_LIBS} #{LIBS}" > > | end > > | > > | desc "Build this extension" > > | file 'foo.so' => OBJ do > > | sh "#{LDSHARED} #{LIBPATH} -o foo.so #{OBJ} #{LIBS}" > > | end > > > > My extension is just one .so file, but there seems to be two ways > > specified here on how to get it: the rule and then the action in the > > file task after it called "foo.so". Aren't all extensions just .so > > files? It seems to me that the ".so" rule might be unnecessary and > > actually ignored by rake. > > I think that was residual from a previous version. I'll remove it for > the release. Ah. Removing the extraneous rule. Check. > > > (BTW, in that ".so" rule above, it says "-o #{OBJ}", but OBJ is an > > array. If that rule were kept, shouldn't there be a #{t.name} squeezed > > in after the "-o"?) > > Nope. Because OBJ comes from SRC.ext (a rake method) it's ready to be > shoved in a compile string. If you find it doesn't work, tell me. Well, I see now that FileList defines its own to_s. Thanks. But it still looks to me like you're supposed to name foo.so after that '-o' before listing the objects. Anyhow, I guess it's moot now since you said you'll be removing that redundant rule before the release anyway. :) > > > > The last thing I notice is, in Generator#rakefile_contents, should > > > > SRC = FileList[#{sources.join(',')}] > > > > instead be > > > > SRC = FileList[#{@sources.join(',')}] > > Nope. If you notice in generator.rb, sources is an accessor which > returns the sources as single quoted strings (which are then joined). Whoops. I see. Thanks. Looking forward to this next release! :D ---John From jmg3000 at gmail.com Tue Sep 19 03:00:37 2006 From: jmg3000 at gmail.com (John Gabriele) Date: Tue, 19 Sep 2006 03:00:37 -0400 Subject: [Mkrf-users] some updates Message-ID: <65e0bb520609190000l3a50cbffvbddfdb3553a19fa5@mail.gmail.com> Hi folks, I made a small update or two to what's in svn: * added an objs attribute to Generator, so you can add objects or shared libs to the link, and * removed the redundant .so rule that was being added to the generated rakefile. Also, I put up a very small homepage for mkrf: http://mkrf.rubyforge.org/ . It's not my design -- it's a public domain one I found on the 'Net. Also, I cleaned up the RF project page by removing the tabs that aren't being used, and added various project details to the trove, as you can see from the RF project page. ---John