Here''s some notes on grouping the compiled bits of the library into separate parts instead of a single wxruby2.so: Each class is loaded and defined in a single file. For class Foo, this will be obj/Foo.o. The function that initialises each file is called Init_wxFoo, generated by SWIG and near the bottom of the source. It will call its parent''s initializer if needed. At the moment, every class is initialised at startup when the main initialisation function in wx.cpp is called, through a function called ''InitializeOtherModules''. The call to this function is defined in swig/wx.i using a SWIG %init block. The rake task ''src/wx.cpp'' in rakewx.rb defines this InitializeOtherModules function and appends it to wx.cpp so that it calls every known class. So, to break a class into a separately loaded file, we have to: 1) Remove Init_wxFoo from the main InitializeOtherModules call in wx.cpp 2) Create a new container/loader file like wx.i which calls Init_wxFoo. Call it wx_foo.i 3) Remove obj/Foo.o from the main linker task 4) Create a new linker task which links obj/Foo.o into a .so file with obj/wx_foo.o 5) require ''wx_foo'' A few further complexities: - Each linker task that creates a separate .so has to know which extra libraries to include - eg libwx_stc for StyledTextCtrl, ''gdiplus.dll'' for GraphicsContext etc - Each separate module would have to have complementary ruby code that requires the relevant ruby files in lib/wx/classes to decorate and extend the compiled code with ruby. This includes, importantly, event handling - the event type definitions mapping event type integer codes to Ruby event classes. This is already done for some classes eg MediaCtrl and StyledTextCtrl. So I think this is all doable but would require a fairly substantial overhaul. I''d be interested to hear what people think about when we should do this in the roadmap. cheers alex
This is very interesting information Alex..... Have you tested the library''s actual hd size, to see if it does reduce in size as far as the separated class into it''s own .so object? Does it have the same size as wxruby2.so, or is it considerably smaller? If it''s considerably smaller then wxruby2.so, then this will be a very worth while setup. If it''s the same size as wxruby2.so, then that''ll break the camel''s back right there, so to say. I say, if the size of the .so file is smaller, then I would say it would be worth while, to see about starting to separate the major classes, that have dependency requirements first. Such as wxMediaCtrl, wxOpenGL, wxStyledTextCtrl for our "Initial" testbed, around 1.9.6 or 1.9.7 versions if not sooner. This way, we can eliminate the need to create a "Minimal" version of wxRuby, and then a feature enriched version of wxRuby. Then we can concentrate, on creating a Single wxRuby distro, that has the basics, then add in the extra stuff, such as wxMediaCtrl, or wxOpenGL, and such, if the person wants to absolutely use it. I think it would be very viable, and worthwhile to pursue this avenue at this stage of development, before we hit 2.0.0 version. Of course, I''m open to hear other comments from others, developers or not. L8ers, On 2/8/08, Alex Fenton <alex at pressure.to> wrote:> > Here''s some notes on grouping the compiled bits of the library into > separate parts instead of a single wxruby2.so: > > Each class is loaded and defined in a single file. For class Foo, this > will be obj/Foo.o. The function that initialises each file is called > Init_wxFoo, generated by SWIG and near the bottom of the source. It will > call its parent''s initializer if needed. > > At the moment, every class is initialised at startup when the main > initialisation function in wx.cpp is called, through a function called > ''InitializeOtherModules''. The call to this function is defined in > swig/wx.i using a SWIG %init block. > > The rake task ''src/wx.cpp'' in rakewx.rb defines this > InitializeOtherModules function and appends it to wx.cpp so that it > calls every known class. > > So, to break a class into a separately loaded file, we have to: > 1) Remove Init_wxFoo from the main InitializeOtherModules call in wx.cpp > 2) Create a new container/loader file like wx.i which calls Init_wxFoo. > Call it wx_foo.i > 3) Remove obj/Foo.o from the main linker task > 4) Create a new linker task which links obj/Foo.o into a .so file with > obj/wx_foo.o > 5) require ''wx_foo'' > > A few further complexities: > - Each linker task that creates a separate .so has to know which extra > libraries to include - eg libwx_stc for StyledTextCtrl, ''gdiplus.dll'' > for GraphicsContext etc > > - Each separate module would have to have complementary ruby code that > requires the relevant ruby files in lib/wx/classes to decorate and > extend the compiled code with ruby. This includes, importantly, event > handling - the event type definitions mapping event type integer codes > to Ruby event classes. This is already done for some classes eg > MediaCtrl and StyledTextCtrl. > > So I think this is all doable but would require a fairly substantial > overhaul. I''d be interested to hear what people think about when we > should do this in the roadmap. > > cheers > alex > > > > > > > > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development >-- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20080209/9c0a2157/attachment-0001.html
Mario Steele wrote:> This is very interesting information Alex..... Have you tested the > library''s actual hd size, to see if it does reduce in size as far as > the separated class into it''s own .so object? Does it have the same > size as wxruby2.so, or is it considerably smaller? II tried removing some big non-core classes like StyledTextCtrl, Grid, Graphics* and the size of the rump wxruby2.so was about 25% smaller. Real gains could be bigger though.> I say, if the size of the .so file is smaller, then I would say it > would be worth while, to see about starting to separate the major > classes, that have dependency requirements first.Agree that size is not the only possible advantage - it''s also being able to include components like MediaCtrl on Linux that depend on third-party libraries without the whole wxruby becoming unusable without those.> I think it would be very viable, and worthwhile to pursue this avenue > at this stage of development, before we hit 2.0.0 version. Of course, > I''m open to hear other comments from others, developers or not.Don''t underestimate how big a task it will likely be. It''ll mean restructuring all the layers in the library from the swig files and the rake process through to the ruby library files. It''ll need a lot of cross-platform test and build to get the .dll / -l arguments to the linker right for each compiled module. I would prefer to continue with only conservative bugfixes plus doc and sample work to the 1.9 series. I would consider adding the ''sizer'' syntax sugar, and dropping MediaCtrl from the pre-comp Linux binary, plus minor missing classes, but other than that no significant changes. I''d hope to get to a stable 2.0 within one or two more releases. To be honest I don''t currently have the time or motivation to start on another major overhaul. But I think this is definitely worth pursuing. If people wish to take it on earlier I''d be very happy to create a SVN branch with a view to a modular wxruby2.2 (or 3.0, if wxWidgets comes out and we move to it) alex