Hi I created an add-on script (to live in rake/) and a little patch for our main rakefile to automate building release products. The two main targets are ''gem'' (create a binary gem for your platform) and ''package'' (create a platform-neutral source tarball for SWIGging and compiling). A few small things came up while doing this: - Package name and version number: what is our upcoming release going to be called? I''ve called it ''wxruby-1.9.0'' here, b/c it looked a bit ugly with numbers in the name (wxruby2) and the version. But easy to change, happy to do this. - $dl_ext on Linux: I forgot what the file extension for compiled Ruby extensions on Linux is: ''.so'' or ''.lib''? - Support for Intel OS X: I had a quick google and can''t see how binary extensions for Intel OS X are supposed to be distinguished in Rubygems system. There seems to be just Gem::Platform::DARWIN, which makes a xxx-powerpc-darwin.gem. Perhaps Sean or someone else on that platform can let me know what filename rubygems gives their gem? Ta cheers alex _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users
Awesome! I tried: rake gem rake package rake gem_osx and they all worked just fine in OS X 10.4 PPC (I will try on my Intel Mac tonight after work) I will also look up what the gem platform name is for x86 Mac OS X. I also like the version naming you have chosen. I am also happy that you did this because I was seriously thinking about giving it a go myself, thanks. Sean On 8/10/06, Alex Fenton <alex at pressure.to> wrote:> Hi > > I created an add-on script (to live in rake/) and a little patch for our > main rakefile to automate building release products.
Hi> I will also look up what the gem platform name is for x86 Mac OS X. >Glad it worked out nicely. I had a poke around in rubygems code, and it turns out that the default suffix for a binary gem is the value of RUBY_PLATFORM (the standard ruby constant). This seems a bit broken to me, not least because it means you get different gem names from doing :gem_osx and :gem - and, on mac powerpc Gem::Platform::CURRENT != Gem::Platform::DARWIN which seems bizarre. Ah well. We can work round it for now cheers alex
On my Intel iMac I get the following gem from the rake gem command: wxruby-1.9.0-i686-darwin8.4.1.gem also Gem::Platform::CURRENT returns "current" Sean On 8/10/06, Alex Fenton <alex at pressure.to> wrote:> Hi > > I will also look up what the gem platform name is for x86 Mac OS X. > > > Glad it worked out nicely. I had a poke around in rubygems code, and it > turns out that the default suffix for a binary gem is the value of > RUBY_PLATFORM (the standard ruby constant). > > This seems a bit broken to me, not least because it means you get > different gem names from doing :gem_osx and :gem - and, on mac powerpc > Gem::Platform::CURRENT != Gem::Platform::DARWIN > > which seems bizarre. Ah well. We can work round it for now > > cheers > alex > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users >
On Thu, 2006-08-10 at 10:21 +0100, Alex Fenton wrote:> I created an add-on script (to live in rake/) and a little patch for our > main rakefile to automate building release products.Sweet!> - Package name and version number: what is our upcoming release going to > be called? I''ve called it ''wxruby-1.9.0'' here, b/c it looked a bit ugly > with numbers in the name (wxruby2) and the version. But easy to change, > happy to do this.I think wxruby2-0.0.x would be the most correct. I think I can live with wxruby-1.9.0, but I would like to think through all the consequences (Rubyforge release listings, Debian package naming, etc).> - $dl_ext on Linux: I forgot what the file extension for compiled Ruby > extensions on Linux is: ''.so'' or ''.lib''?Compiled extensions (the equivalent of Windows .dll) are .so Kevin
Sean Long wrote:> On my Intel iMac I get the following gem from the rake gem command: > > wxruby-1.9.0-i686-darwin8.4.1.gem >Thanks - I''ve just posted a q to the newsgroup to find out whether there are compatibility issues with different versions of XCode (eg 8.4.1, 7.9.0) on the same architecture. Hopefully we can just build powerpc-darwin and i686-darwin - I''ve added a little hack to the rake script to fix the output filenames.> also Gem::Platform::CURRENT returns "current" >Hehe - not very helpful is it? alex
>> - Package name and version number: what is our upcoming release going to >> be called? I''ve called it ''wxruby-1.9.0'' here, b/c it looked a bit ugly >> with numbers in the name (wxruby2) and the version. But easy to change, >> happy to do this. >> > > I think wxruby2-0.0.x would be the most correct. I think I can live with > wxruby-1.9.0, but I would like to think through all the consequences > (Rubyforge release listings, Debian package naming, etc). >My thinking here, aside from aesthetics, is that the release we''re working on will eventually (soon?!) supplant the wxruby 0.x.x series, which were development releases towards wxruby v1.0. We don''t seem to have a situation like sqlite/sqlite3 where there are reasons for long-term maintenance of two distinct stable packages with different features. Our differences lie in internal engineering rather than end-user functionality. re Rubyforge I think that the ''odd minor version equals development'' convention is well embedded in Ruby practice generally - eg current core Ruby.>> - $dl_ext on Linux: I forgot what the file extension for compiled Ruby >> extensions on Linux is: ''.so'' or ''.lib''? >> > > Compiled extensions (the equivalent of Windows .dll) are .so >Thanks - will update the rake scripts alex
On Fri, 2006-08-11 at 10:27 +0100, Alex Fenton wrote:> My thinking here, aside from aesthetics, is that the release we''re > working on will eventually (soon?!) supplant the wxruby 0.x.x series, > which were development releases towards wxruby v1.0.Ok.> re Rubyforge I think that the ''odd minor version equals development'' > convention is well embedded in Ruby practice generally - eg current core > Ruby.I have never liked that convention much. For development tools (like wxruby) it''s ok. For end-user apps, no way. Does 1.0 count as even or odd? What about 2.1? Or 1.2.1? But regardless of that, we should be aiming toward 1.0. I just built a gem. Then I installed it, which said it worked, but when I tried to run a wxruby app it couldn''t find wxruby. Is there a way to mention at gem-install time where the samples are being placed? Kevin