After you get the mingw compilation going, it seems to me like setting up a script to compile it nightly wouldn''t be too hard. Oh--except for the one click aspect. So far the only error I''ve really found is that running ruby-e "\"" anything quotes in quotes causes problems. Maybe we can put a link on the main page to the mingw one until we get feedback for it. Something side by side. What is the problem with having two? With the normal OCI it gives tons of libraries, most of which are unused, and if there are some that are used, users can just install the gem with no problem. Maintaining a slimmed down version seems like it would be cake, once you get one going. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubyinstaller-devel/attachments/20071106/60636081/attachment.html
On 11/7/07, Roger Pack <rogerpack2005 at gmail.com> wrote:> After you get the mingw compilation going, it seems to me like setting up a > script to compile it nightly wouldn''t be too hard. Oh--except for the one > click aspect.Part of the Installer is the One-Click ;-)> So far the only error I''ve really found is that running ruby-e "\"" anything > quotes in quotes causes problems. >Did you tried -e ''puts "hello"'' instead of the quad quotes? (double-double quotes)> Maybe we can put a link on the main page to the mingw one until we get > feedback for it. Something side by side. What is the problem with having > two?I still have my reservations about mingw/vc8 builds. Another kind of package right now will get us a lot of troubles since we are in RC stage. After OCI hits stable we will start the brain storm process for the upcoming release. The whole build process should be automated, and the package building (Windows Installer + Merge Modules) for the extensions and libraries.> With the normal OCI it gives tons of libraries, most of which are unused, > and if there are some that are used, users can just install the gem with no > problem.Yeah, user get a lot of things out of the box, but sometimes some gems requires the compiler, which is another issue we must face.> Maintaining a slimmed down version seems like it would be cake, once you get > one going.The whole idea is start from scratch, be modular and easily testable, taking as experience what we learned from OCI.> Thoughts?I guess you can collect all the comments I made previously to this topic in ruby-talk and here :-) -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi
On 11/6/07, Luis Lavena <luislavena at gmail.com> wrote:> > On 11/7/07, Roger Pack <rogerpack2005 at gmail.com> wrote: > > With the normal OCI it gives tons of libraries, most of which are > unused, > > and if there are some that are used, users can just install the gem with > no > > problem. > > Yeah, user get a lot of things out of the box, but sometimes some gems > requires the compiler, which is another issue we must face. >Over the years I have definitely cut back on the included extensions, encouraging the use of RubyGems instead. The guiding factors that I have used are that OCI should out-of-the-box 1) support the Windows platform (this means including the core Win32 gems), and 2) should include modest newbie tools to help them explore Ruby. #2 is why OCI includes fxri (which is good for seasoned rubyists as well as newbies). Including fxri requires the inclusion of FXRuby. I''ve tried to get someone to write a GUI interface to RubyGems, without any luck. If someone had done that, I would have included it. Also, since database programming and web programming are very popular uses, including DBI and OpenSSL make a lot of sense. Curt Gui RubyyGems -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubyinstaller-devel/attachments/20071107/cc4c516e/attachment.html