Hi all, I''ve been going over the chapters on RDOC and gems lately. I think we should probably work on making the code in Win32Utils "rdoc" friendly. I''ve started doing this with ''win32-ipc'' as an experiment. This probably means some directory reorganization, because I think gems looks for extensions in an ''ext'' directory, whereas we have everything under ''lib'' for now. I''ll change that if I have to. I may also move the ''examples'' subdirectory to the toplevel. I''m in no big hurry to do this, however. I''m not finding rdoc to be very flexible or friendly and some things don''t work the way I think they ought to. Also, I know this probably means delaying another release of the installer. However, I like the ri documentation, so if that means switching to rdoc over rd, so be it. I plan on keeping the .txt and .rd files around, though. I''ll use win32-ipc as an experiment and see how it goes. Dan
Hi, win32utils-devel@rubyforge.org wrote:>Hi all, > >I''ve been going over the chapters on RDOC and gems lately. I think we >should probably work on making the code in Win32Utils "rdoc" friendly. >I''ve started doing this with ''win32-ipc'' as an experiment. > >This is a very good idea !>This probably means some directory reorganization, because I think gems >looks for extensions in an ''ext'' directory, whereas we have everything >under ''lib'' for now. I''ll change that if I have to. I may also move >the ''examples'' subdirectory to the toplevel. > >During the Conference, Chad and Jim had very patiently explained to me the process of creating gems (thanks a lot, Chad, Jim) and Jim has shown me how I could use rake to automate the build. I was planning to put it all together before our next release but the thought languished. But I remember Chad mentioning to me that if we have a one-click installer then we do not need the gems (and vice-versa). Not that it matters though, since we can (and should) always offer both options :-) The one-click installer has a slight advantage in that we can put our sample/test files in any folder of our choice which is not (yet) possible using gems. Or is it? Dan, I will like to build on the code (gemspec/rakefile) I had written at the conference if it is OK by you. Let me know...>I''m in no big hurry to do this, however. I''m not finding rdoc to be >very flexible or friendly and some things don''t work the way I think >they ought to. Also, I know this probably means delaying another >release of the installer. However, I like the ri documentation, so if >that means switching to rdoc over rd, so be it. I plan on keeping the >.txt and .rd files around, though. > >Yes, no hurry (especially when I have not much time for a couple of weeks ;-)).>I''ll use win32-ipc as an experiment and see how it goes. > >Cool ! Keep up the good work.>Dan > >-- Shashank
(Sorry if you''ve gotten more than one copy of this...mail client issues) Hi. Not sure if this will make it to the list, but let''s see. Comments below.> Hi, > > win32utils-devel@rubyforge.org wrote: > >>Hi all, >> >>I''ve been going over the chapters on RDOC and gems lately. I think we >>should probably work on making the code in Win32Utils "rdoc" friendly. >>I''ve started doing this with ''win32-ipc'' as an experiment. >> >> > This is a very good idea ! > >>This probably means some directory reorganization, because I think gems >>looks for extensions in an ''ext'' directory, whereas we have everything >>under ''lib'' for now. I''ll change that if I have to. I may also move >>the ''examples'' subdirectory to the toplevel. >> >>Actually rubygems doesn''t _require_ that you use the lib and ext directories this way. But it''s generally thought to be good packaging etiquette to do so. You can put an extconf.rb anywhere you like and just specify it in the "extensions" attribute of the gemspec. Same goes for "requirepath".> During the Conference, Chad and Jim had very patiently explained to me > the process of creating gems (thanks a lot, Chad, Jim) and Jim has shown > me how I could use rake to automate the build. > > I was planning to put it all together before our next release but the > thought languished. But I remember Chad mentioning to me that if we have > a one-click installer then we do not need the gems (and vice-versa). > Not that it matters though, since we can (and should) always offer both > options :-) > The one-click installer has a slight advantage in that we can put our > sample/test files in any folder of our choice which is not (yet) > possible using gems. Or is it? >So, based on the above, the advantage you list here is moot. Generally, though, if Windows users have a standard Windows installer, the typical pain of installing libraries goes away, so the advantage of RubyGems is a little less marked. It may, however, be easier for someone to automate the installation of libraries if they''re available as RubyGems. And it''s really easy to upgrade. I think there''s something to be said for having the same interface for installing as many libraries as once. For example, if you wanted to use both BlueCloth and the speech API bindings in the same program, it''s nice to just do: gem install bluecloth gem install speech (or whatever it would be called. All in all, you guys are really creating some good stuff. Regardless of what the _best_ solution is, I would be thrilled to see this stuff installable as gems. One last thing I left out is that when Curt goes to Gems-based installation of libs for the one-click installer, having these as Gems will really help to get you integrated into that project, which would be great. Thanks, Chad
Hi all, <snip>> > But I remember Chad mentioning to me that if we > > have a one-click installer then we do not need the gems (and > > vice-versa). Not that it matters though, since we can (and should) > > always offer both options :-) The one-click installer has a slight > > advantage in that we can put our sample/test files in any folder of > > our choice which is not (yet) possible using gems. Or is it? > > > > So, based on the above, the advantage you list here is moot. > Generally, though, if Windows users have a standard Windows > installer, the typical pain of installing libraries goes > away, so the advantage of RubyGems is a little less marked. > It may, however, be easier for someone to automate the > installation of libraries if they''re available as RubyGems. > And it''s really easy to upgrade.My real motivation for wanting both gems and an installer is that the individual packages tend to get ahead of our installer. Considering the number of packages we have, I think it''s a bit unrealistic to put out a new installer every time I decide to scratch an itch and put out a new release for a given package (which I tend to do often). Having a gem immediately available for individual packages would be nice for folks who can''t/don''t have a compiler and don''t want to wait for the next release of the installer. But, I still want the installer, too.> One last thing I left out is that when Curt goes to Gems-based > installation of libs for the one-click installer, having > these as Gems will really help to get you integrated into thatproject, which would be great. The possible integration with Curt''s installer is a bonus. :)> I think there''s something > to be said for having the same interface for installing as > many libraries as once.Yep, there''s that, too. :) Dan
Hi, win32utils-devel@rubyforge.org wrote: <snip>>So, based on the above, the advantage you list here is moot. >Oh, great ! So we will be able to put the samples in the c:\ruby\samples\win32utils folder then. That is really wonderfull!>It may, however, be easier for someone to automate >the installation of libraries if they''re available as RubyGems. And it''s >really easy to upgrade. I think there''s something to be said for having >the same interface for installing as many libraries as once. > >Touch?.>All in all, you guys are really creating some good stuff. Regardless of >what the _best_ solution is, I would be thrilled to see this stuff >installable as gems. > >Thanks. It will be ... very soon.>One last thing I left out is that when Curt goes to Gems-based >installation of libs for the one-click installer, having these as Gems >will really help to get you integrated into that project, which would be >great. > >Splendid !!>Thanks, >Chad > >Thank you, -- Shashank