The attached patch fixes the task for non-gem installation. It adds installation of the version and class ruby files, and puts things in the right place (wx.rb was previously going into sitearchdir). It also adds an uninstall task. I plan to overhaul the rake system at some point soon as I think it could be declared more simply, and to avoid launching a new process for each of the cpp post-processors. Once this is in, and the App patch has been applied, I think we should tag and release. I''ll check in App.i if I don''t hear any objections. I''ll resubmit IconBundle etc later with a proper sample, cos it does need testing on Windows where icons work differently to OS X. alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rake_install.patch Url: http://rubyforge.org/pipermail/wxruby-development/attachments/20061023/66526e95/attachment.ksh
Alex Fenton wrote:> The attached patch fixes the task for non-gem installation. It adds > installation of the version and class ruby files, and puts things in > the right place (wx.rb was previously going into sitearchdir). It also > adds an uninstall task. > > I plan to overhaul the rake system at some point soon as I think it > could be declared more simply, and to avoid launching a new process > for each of the cpp post-processors.Should we take a look at mkrf[1]? I''m not entirely certain it''s something we want but it was discussed at RubyConf.> > Once this is in, and the App patch has been applied, I think we should > tag and release. I''ll check in App.i if I don''t hear any objections. > > I''ll resubmit IconBundle etc later with a proper sample, cos it does > need testing on Windows where icons work differently to OS X. >I''ll test out the attached patch and look over IconBundle when you [re-]submit it. [1] http://rubyforge.org/projects/mkrf/
Roy Sutton wrote:> Alex Fenton wrote: >> >> >> I plan to overhaul the rake system at some point soon as I think it >> could be declared more simply, and to avoid launching a new process >> for each of the cpp post-processors. >> > Should we take a look at mkrf[1]? I''m not entirely certain it''s > something we want but it was discussed at RubyConf. >Funny, I was looking at it earlier browsing the RubyConf blogs. I''d be willing to give it a go once it''s a bit more mature and documented. Actually, I think our build system is OK, and it''s got a lot of learning and platform/compiler knowledge embedded in it. I''d really just like to tidy it up and make it a bit easier to follow. I think we could make better use of rake features (eg synthetic rules), use constants rather than globals where possible, so uninitialised or overwriting settings is warned aobut, and declare the tasks straightforwardly. I''d like to fix dependency checking so that changes to superclasses trigger a recompile of subclasses, add stripping of OS X binaries, and tidy the postprocessors. But none of those is very high priority.>> Once this is in, and the App patch has been applied, I think we should >> tag and release. I''ll check in App.i if I don''t hear any objections. >> > I''ll test out the attached patchThanks. After that''s in, unless we hear there''s major problems on a platform, let''s go for a release. alex
Apparently Analagous Threads
- Installing from source missing -lruby18 in linking.
- 0.0.37 release?
- [PATCH] let the user explicitly choose ruby and rake programs
- [PATCH] hivex: Fix Ruby bindings for 1.9; let the user explicitly choose ruby, rake
- [PATCH] hivex: ruby: Support 'make INSTALLDIRS=vendor install' for Ruby