Wrapping things for 1.9.2-p0 - use-devkit

7 views
Skip to first unread message

Luis Lavena

unread,
Aug 18, 2010, 4:47:28 PM8/18/10
to rubyin...@googlegroups.com
Hello,

I wanted to push forward with use-devkit branch and I'm working now in
ensure it compiles and works with 1.9.2-p0 that was released a few
hours ago.

If nobody objects, I would like merge use-devkit branch to master and
be the foundation for newer installers.

This means 1.9.2-p0 will go out with GCC 4.5.0, which will require
newer DevKit. Experimental DevKit is out at GitHub, but more work is
needed.

I would like to avoid holding 1.9.2 release for long time, specially
since lot of people is waiting for it.

What do you guys think?
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

Jon

unread,
Aug 18, 2010, 5:01:53 PM8/18/10
to rubyin...@googlegroups.com
> I wanted to push forward with use-devkit branch and I'm working now in
> ensure it compiles and works with 1.9.2-p0 that was released a few
> hours ago.
>
> If nobody objects, I would like merge use-devkit branch to master and
> be the foundation for newer installers.
>
> This means 1.9.2-p0 will go out with GCC 4.5.0, which will require
> newer DevKit. Experimental DevKit is out at GitHub, but more work is
> needed.

I successfully build 1.9.2-p0 with the use-devkit branch and have been experimenting with rails-3.0.0.rc and other things.

While there's a bit more polishing needed on the newer DevKit, I've heard of no hard failures and one can always build it with "rake devkit sfx=1", or download one of the experimental versions from our GitHub project page.

I vote for merging and releasing :)

Jon

Boško Ivanišević

unread,
Aug 18, 2010, 5:02:27 PM8/18/10
to rubyin...@googlegroups.com
On Wed, Aug 18, 2010 at 10:47 PM, Luis Lavena <luisl...@gmail.com> wrote:
Hello,

I wanted to push forward with use-devkit branch and I'm working now in
ensure it compiles and works with 1.9.2-p0 that was released a few
hours ago.

If nobody objects, I would like merge use-devkit branch to master and
be the foundation for newer installers.

This means 1.9.2-p0 will go out with GCC 4.5.0, which will require
newer DevKit. Experimental DevKit is out at GitHub, but more work is
needed.

I would like to avoid holding 1.9.2 release for long time, specially
since lot of people is waiting for it.

What do you guys think?

I agree with you. I'm on use-devkit branch on Window 7 x64  for more than a week and it works without any problem.

--
Regards,
Boško Ivanišević

Chuck Remes

unread,
Aug 18, 2010, 5:16:37 PM8/18/10
to rubyin...@googlegroups.com
I have also been experimenting with this branch on win7 x64. It's working nicely.

I think you should go forward with your plan.

cr

Luis Lavena

unread,
Aug 18, 2010, 5:32:36 PM8/18/10
to rubyin...@googlegroups.com

Thank you guys.

I just tested the merge and everything worked as expected.

I'm not going to release 1.9.2-p0 installers yet, want to better
document the switch of GCC and what DevKit should be used instead.

Dušan Majkić

unread,
Aug 19, 2010, 7:00:14 AM8/19/10
to rubyin...@googlegroups.com
> What do you guys think?

Devkit completly changed my ruby experience on the windows platform.

It should be made available as default with rubyinstaller, or as an
easy add-on or gem.

Luis Lavena

unread,
Aug 19, 2010, 8:06:27 AM8/19/10
to rubyin...@googlegroups.com
2010/8/19 Dušan Majkić <dma...@gmail.com>:

Thank you for your comment Dušan, we have another thread there we
discussed the DevKit approach and decided a separate installer will be
available.

That will give the option for further customization of deployment scenarios.

Robert Calco

unread,
Aug 19, 2010, 8:08:58 AM8/19/10
to rubyin...@googlegroups.com

2010/8/19 Dušan Majkić <dma...@gmail.com>

I totally agree with that. Should be part of the distro... Without it Ruby's value proposition on Windows would be "less than" that of Ruby on any other platform. I've found the inability to install certain gems without a binary-compatible compiler to be a bit like trying to brush your teeth without a toothbrush. Like decaffinated coffee.. or non-alcoholic beer... or non-adhesive tape...

Seriously... Ruby should "just work" out of the box. Even on Windows. Please include the DevKit!

- Bob
 

--
You received this message because you are subscribed to the Google Groups "RubyInstaller" group.
To post to this group, send email to rubyin...@googlegroups.com.
To unsubscribe from this group, send email to rubyinstalle...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyinstaller?hl=en.


Robert Calco

unread,
Aug 19, 2010, 8:12:57 AM8/19/10
to rubyin...@googlegroups.com
On Thu, Aug 19, 2010 at 1:06 PM, Luis Lavena <luisl...@gmail.com> wrote:
2010/8/19 Dušan Majkić <dma...@gmail.com>:
>> What do you guys think?
>
> Devkit completly changed my ruby experience on the windows platform.
>
> It should be made available as default with rubyinstaller, or as an
> easy add-on or gem.
>

Thank you for your comment Dušan, we have another thread there we
discussed the DevKit approach and decided a separate installer will be
available.

That will give the option for further customization of deployment scenarios.

OK, at least make it an optional part of the installation. By default checked!

I for one cannot fathom when I would ever NOT want the compiler, even if was a production deployment scenario. Only if I forgo the use of many great gems that are written or require C extensions. Why would I do that?

- Bob
 
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

--

Luis Lavena

unread,
Aug 19, 2010, 8:32:07 AM8/19/10
to rubyin...@googlegroups.com
On Thu, Aug 19, 2010 at 9:08 AM, Robert Calco <bobc...@gmail.com> wrote:
>
> 2010/8/19 Dušan Majkić <dma...@gmail.com>
>>
>> > What do you guys think?
>>
>> Devkit completly changed my ruby experience on the windows platform.
>>
>> It should be made available as default with rubyinstaller, or as an
>> easy add-on or gem.
>
> I totally agree with that. Should be part of the distro... Without it Ruby's
> value proposition on Windows would be "less than" that of Ruby on any other
> platform. I've found the inability to install certain gems without a
> binary-compatible compiler to be a bit like trying to brush your teeth
> without a toothbrush. Like decaffinated coffee.. or non-alcoholic beer... or
> non-adhesive tape...
>
> Seriously... Ruby should "just work" out of the box. Even on Windows. Please
> include the DevKit!
>

Hello Bob,

While I understand your sentiment and fully share the experience you
and many others suffer, I'm not fond to bundle the DevKit into the
installer.

Bundling put us in a delicate situation, where any update of the
involved packages require a new installer release. This was one of the
things the old One-Click Installer suffered.

I had shared my personal thoughts on bundling stuff in the past, and
one more precisely in text editors area.

I understand that certain gems are not provided as binaries for
Windows developers, but tools like rake-compiler have been created to
solve that. Is not up to the developers to start using it.

There are also gems that requires more work, like 3rd party libraries
and headers. Even installing those gems requires a change in the
Windows user culture -- compile things is not for everybody.

What I'm trying is to slowly generate that culture, and imposing
things into people never generated good results. Better documentation,
Guides and developers caring, these change things.

Leonardo Valeri Manera

unread,
Aug 19, 2010, 8:41:21 AM8/19/10
to rubyinstaller

An admirable aim!

In the meanwhile, might I suggest that the main installer do like, for
example, LyX does with MiKTeX and ghostscript?

Which is to say, check the registry to see if its installed (or
installed but too low a version), and if not, ask the user if he wants
to download & install, with a default of yes?

This is the best solution I've seen yet for this kind of problem.

Cheers,
Leo

Luis Lavena

unread,
Aug 19, 2010, 8:48:22 AM8/19/10
to rubyin...@googlegroups.com
On Thu, Aug 19, 2010 at 9:41 AM, Leonardo Valeri Manera
<l.valer...@gmail.com> wrote:
>
> An admirable aim!
>
> In the meanwhile, might I suggest that the main installer do like, for
> example, LyX does with MiKTeX and ghostscript?
>
> Which is to say, check the registry to see if its installed (or
> installed but too low a version), and if not, ask the user if he wants
> to download & install, with a default of yes?
>
> This is the best solution I've seen yet for this kind of problem.
>

I would suggest we get the planned DevKit working and out (the one
that detects installed Ruby), then we can start looking on how to
improve the RubyInstaller 'install' process to advertise, detect or
something.

As Ruby, I would love to have a choice on how do things.

Robert Calco

unread,
Aug 19, 2010, 8:56:27 AM8/19/10
to rubyin...@googlegroups.com
On Thu, Aug 19, 2010 at 1:32 PM, Luis Lavena <luisl...@gmail.com> wrote:
On Thu, Aug 19, 2010 at 9:08 AM, Robert Calco <bobc...@gmail.com> wrote:
>
> 2010/8/19 Dušan Majkić <dma...@gmail.com>
>>
>> > What do you guys think?
>>
>> Devkit completly changed my ruby experience on the windows platform.
>>
>> It should be made available as default with rubyinstaller, or as an
>> easy add-on or gem.
>
> I totally agree with that. Should be part of the distro... Without it Ruby's
> value proposition on Windows would be "less than" that of Ruby on any other
> platform. I've found the inability to install certain gems without a
> binary-compatible compiler to be a bit like trying to brush your teeth
> without a toothbrush. Like decaffinated coffee.. or non-alcoholic beer... or
> non-adhesive tape...
>
> Seriously... Ruby should "just work" out of the box. Even on Windows. Please
> include the DevKit!
>

Hello Bob,

While I understand your sentiment and fully share the experience you
and many others suffer, I'm not fond to bundle the DevKit into the
installer.

Bundling put us in a delicate situation, where any update of the
involved packages require a new installer release. This was one of the
things the old One-Click Installer suffered.

I hear ya.

At the end of the day as long as it's easy and intuitive to get it installed quickly and correctly, that's all that matters.

But I for one would never "not want" the DevKit installed so I would prefer if that was not something that took two clicks when one click might do. ;)

I understand your points though, and would like to thank you and others working on this to get the Ruby One-Click installed to the current state, which is better than it's ever been for Ruby coders who have to work on or deploy to Windows.

:)

- Bob


I had shared my personal thoughts on bundling stuff in the past, and
one more precisely in text editors area.

I understand that certain gems are not provided as binaries for
Windows developers, but tools like rake-compiler have been created to
solve that. Is not up to the developers to start using it.

There are also gems that requires more work, like 3rd party libraries
and headers. Even installing those gems requires a change in the
Windows user culture -- compile things is not for everybody.

What I'm trying is to slowly generate that culture, and imposing
things into people never generated good results. Better documentation,
Guides and developers caring, these change things.

--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

--

Jon

unread,
Aug 19, 2010, 9:07:09 AM8/19/10
to rubyin...@googlegroups.com
> > In the meanwhile, might I suggest that the main installer do like, for
> > example, LyX does with MiKTeX and ghostscript?
> >
> > Which is to say, check the registry to see if its installed (or
> > installed but too low a version), and if not, ask the user if he wants
> > to download & install, with a default of yes?
> >
> > This is the best solution I've seen yet for this kind of problem.
> >
>
> I would suggest we get the planned DevKit working and out (the one
> that detects installed Ruby), then we can start looking on how to
> improve the RubyInstaller 'install' process to advertise, detect or
> something.

@Leo, @Bob,

Check out the installer for http://pidgin.im/ and tell us what you think of how they handle downloading-GTK-as-part-of-the-install process, both from a technical perspective (support issues, etc?) and as end-users.

Notice where they put the Gtk runtime and what they put in the registry for the "Add or Remove Programs" dialog.

Also, if either of you have the interest I'd love to see you fork our repo and whip up a branch with Inno installer tweaks for us to look at for updates to the existing installer.

Jon

Leonardo Valeri Manera

unread,
Aug 19, 2010, 9:38:18 AM8/19/10
to rubyinstaller
On 19 August 2010 15:07, Jon <jon.f...@gmail.com> wrote:
>> > In the meanwhile, might I suggest that the main installer do like, for
>> > example, LyX does with MiKTeX and ghostscript?
>> >
>> > Which is to say, check the registry to see if its installed (or
>> > installed but too low a version), and if not, ask the user if he wants
>> > to download & install, with a default of yes?
>> >
>> > This is the best solution I've seen yet for this kind of problem.
>> >
>>
>> I would suggest we get the planned DevKit working and out (the one
>> that detects installed Ruby), then we can start looking on how to
>> improve the RubyInstaller 'install' process to advertise, detect or
>> something.
>
> @Leo, @Bob,
>
> Check out the installer for http://pidgin.im/ and tell us what you think of how they handle downloading-GTK-as-part-of-the-install process, both from a technical perspective (support issues, etc?) and as end-users.
>
> Notice where they put the Gtk runtime and what they put in the registry for the "Add or Remove Programs" dialog.

Pidgin has recently changed their process - they used to install GTK
as a separate package if you didn't have it - now by default they
install a local copy in INSTALLDIR\Gtk.

This was arguably a good idea for them, insofar as since they're not
the only users of GTK in a system, potentially, now they're not
getting bug reports due to the system GTK being a version that doesn't
work well with pidgin. It also handily frees them from having to
support all versions of Gtk which might conceivably be installed by,
say, old versions of WinGimp.

Its a little different for the DevKit, in that since its only supposed
to be used through the DevKit gems hook, and you're also the provider
of the devkit, insomuch as anyone is ever the provider of an OSS
package, you don't need such totalitarian control over the
installation of it.

The RubyInstaller should (and yes, once 1.9.2 and the new devkit kinks
have been worked out to your satisfaction, not now) check during
install for presence of devkit.

If its not present, it should check the tickmark that causes the
installer to download and install it. The default location of such an
install can be discusses when that bridge is crossed but given how
much msys likes spaces I suspect something like
C:\RubyDevKit\<version> is preferable. Pretty much everything else
unix-derived that's a developer tool does the same, ActivePerl
defaults to C:\Perl, etc.

If its present, but the version is < required version, it should offer
to upgrade it, with an option for parallel installation (visibly mark
that as "for advanced users", as anyone who actually needs 2 different
devkit versions presumably knows what they're doing). Upgrading in
this case would mean calling uninstall on the older version(s) before
installing the new one.

If its present and recent enough, uncheck the option to install, and
possibly auto-install the hook for it into the newly-installed ruby.

Given the platform we're working on I think that's the best solution possible.

This is not to say that having each copy of rubyinstaller keep its own
DevKit, but I don't think it would noticeably decrease support
problems over a managed external solution as detailed above. I'm also
a little iffy about duplicating a 70mb+ package for each ruby install
- some of us run SSDs :)

Cheers,
Leo

Jon

unread,
Aug 19, 2010, 9:49:01 AM8/19/10
to rubyin...@googlegroups.com
> Its a little different for the DevKit, in that since its only supposed
> to be used through the DevKit gems hook, and you're also the provider
> of the devkit, insomuch as anyone is ever the provider of an OSS
> package, you don't need such totalitarian control over the
> installation of it.

Indeed. I think we want the DevKit to be accessible by all installed Rubies rather than a private version like Pidgin. I do like how they download and extract the Gtk zip rather than embedding it in the installer.

Note that in addition to the gems pre_install hook, the DevKit can be brought into your development work via "ruby -rdevkit extconf.rb".


> This is not to say that having each copy of rubyinstaller keep its own
> DevKit, but I don't think it would noticeably decrease support
> problems over a managed external solution as detailed above. I'm also
> a little iffy about duplicating a 70mb+ package for each ruby install
> - some of us run SSDs :)

I also prefer a shared DevKit rather than duplicating its artifacts over the filesystem as a private prt of each RubyInstaller copy. I also _do not_ want the RubyInstaller's to grow in size by including the DevKit in each installer.

Thanks for your feedback on how you think the installer and the DevKit should behave.

Jon

Jon

unread,
Aug 19, 2010, 11:02:28 AM8/19/10
to rubyin...@googlegroups.com
> I just tested the merge and everything worked as expected.
>
> I'm not going to release 1.9.2-p0 installers yet, want to better
> document the switch of GCC and what DevKit should be used instead.

I just built ruby trunk (1.9.3dev 29056) with master and it looks good.

Regarding releasing the 1.9.2-p0 installer, I agree that the usage documentation at http://wiki.github.com/oneclick/rubyinstaller/development-kit needs to be finished before releasing the installer and the new DevKit.

I've been working with the JRuby folks so that new DevKit can be used with their new (unreleased) feature[1] to support native extensions such as rdiscount, curb, eventmachine, etc. While the DevKit (with helper .bat's) currently builds both their native support library and some native gems, we're still working through the issue. The good news is that any required DevKit changes appear to be isolated to DevKit's dk.rb helper install script and maybe a couple helper .bat's. The "core" MSys/MinGW/TDM parts of the DevKit that we count on for RubyInstaller installs continue to work fine as-is.

As DevKit's JRuby support is for one of their unreleased features and it's not clear how long it will take to finish polishing up, I plan to switch my priority to creating the Wiki docs in preparation for an ASAP 1.9.2-p0 and new DevKit release. I plan to release an updated DevKit with full JRuby support once the issues get resolved, but I don't think holding up 1.9.2-p0 installers and the new DevKit makes sense.

Thoughts?

Jon

[1] http://blog.headius.com/2010/07/what-jruby-c-extension-support-means-to.html

Reply all
Reply to author
Forward
0 new messages