[Rubyinstaller-devel] Migrate to GCC as soon as possible?
luislavena at gmail.com
Sun Nov 30 09:13:39 EST 2008
On Sun, Nov 30, 2008 at 5:10 AM, Joao Pedrosa <joaopedrosa at gmail.com> wrote:
>> Yes, rubyinstaller bugs should be fixed soon. Been focusing energy in
>> the new scripts and some helpers to solve the issues of several
> BTW. Being the Ruby Installer a rather special kind of software
> building/installing, would not it be better to keep everything in Ruby
> itself so it could more easily be understood by everyday's programmer
> than to use Rake to its fullest which might be a little beyond potential
> contributor's skills?
Indeed the project started as pure-ruby driving the ruby build
process, which included download of source files and even unpacking
those without external dependencies, but not as custom scripts.
Instead is driven by Rake.
AFAIK Rake is the best tool for the job. Other projects created a
specific DSL that generates the needed Rake tasks. Reinventing the
wheel is out of question.
What we found is that using current implementation, building multiple
versions of ruby or the tools Ruby depends on (which are more than 10)
get's complicated and messy.
You can confirm this statement looking at the recipes on github repository:
The DSL been working on add a better designed layer on top of it,
taking in consideration the issues we found with current one.
> It's not as if there is lots of people willing to even try it, let
> alone to put into
> it the energy required to understand it. I know that Rake doesn't look
> that scary, and it might even be handy... I just fear that in the long run it
> might be a waste and make the installer harder to integrate with or understand.
One of the things that made me decide step back and look at this new
DSL on top of Rake is lower the entry point to users.
The new structure encourage a event-driven concept of tasks, what
should happen before of after a operation.
If you compare that with current implementation, will see is much more clear.
Just an example, will work on complete the DSL implementation now that
rake-compiler is usable:
> There is already RubyGems, setup.rb... And numerous nuisances when
> trying to make things install in the right ways... By appealing to the
> full power
> of Ruby it could prove more than useful.
Oh, we are not reinventing the wheel on this. The objective is have
Ruby and their dependencies built properly and in a stable way, so we
can run the tests and trust the things we build, in a more automated
fashion of current implementation.
RubyGems gem installation will be the official way to install stuff on
new installer, the only thing is that rubygems needs setup.rb to
install itself ;-)
Maybe I should put a manifesto about this? I thought the wiki pretty
well exposed our goals:
> In the lines of "beware of premature optimization", I would say to
> "beware of premature frameworkzation" in this case. Even though the Ruby
> Installer would have to adopt its own framework structure for sure. My worry
> is that it has to handle with external issues all the time, or in the words
> of Linux Distributions, with "upstream".
I agree, but in the land of Windows users, there is no alternative for us.
Current installer scripts (installer2) is a single file that drives
the whole show.
It not only bundles everything under the sun, but there is no
automated way to verify it. Moreover, it depends on a external build
of ruby (VC6) which we don't have control over, and thus require
manual steps that make generating, testing and packaging new releases
When we reached that point, the work on the new set of scripts proven
to be more easy:
Based on a free compiler, we have all the control over the build process
Everything well detailed, presenting the dependency chain to the user
(ruby depends on openssl and readline).
Focusing on the core, not the 150 gems bundled on previous version
We need to build everything, which some projects don't make it easy
(yeah, that goes for GNU projects)
The "detailed" recipes couldn't scale to handle more than one time of
version (check the hooks for CHECKOUT and will see the dilemma).
Based on those things, I started to explore how to solve that without
exposing the dirty details and keep things under control and
The new DSL tries to solve that, yet still is not ready to replace
current implementation but will be more easy to jump in for new users.
After all, is a descriptive way of detail steps and things that should
happen after and before each of the actions by default a version will
1) download code
2) unpack it
3) execute the configure script
5) make install
Those steps has been present in most of every tool and even linux
distro under the sun... Why not rely on that?
> Take that as just an idea.
Point taken, but please review my comments again and see if it still apply.
I'm very passionate about what I do, so all these things can be a bit biased.
One thing that I noticed was a bad choice is go with Windows Installer
(MSI) technology. While is worth it, rely on WiX and XML to build the
components is too complex to be easily maintained.
>> Is good to know VC6 build was beaten by both Jruby and MinGW build!
> I have some more data to corroborate. More in another email.
>> Every time I test jruby I don't enable any of these flags since
>> "average joe ruby" will need to dig into the documentation or some
>> sites to get info from them.
>> In any case, these should be enabled by default, right? These are safe
>> to be used by average joe?
> Yes, JRuby's flags like "--server", "-X-C" can be safely used by users,
> they are only required to have the JDK to be able to choose.
> Also, the JDK seems to be able to adopt one or another internal
> VM automatically if the computer seems adequate, as in a server
> machine with plenty of RAM and multiple CPUs.
> The "-X-C" works more as a testing facility to disable the ruby to bytecode
> compiler. The important flag is "--server" because it enables the
> ruby to bytecode compiler and uses the more performance-seeking
> hotspot VM.
> In single-run algorithms, JRuby should work well enough without the
> need to use such flags. It's only if you are running longer-running
> algorithms or server services that using the "--server" flag might
> pay off.
> JRuby could still enjoy some tunning to achieve greater performances,
> and a future JVM version could further help it achieve that. :-)
I cannot say too much about JRuby, I'm not even a user of it.
>> For example, MinGW version is built with zero flag optimization, and
>> it's even including debug information (-g) to ease the debug process
>> while developing the package.
> I managed to disable the "-g" flag during my most recent tests and it
> didn't seem to significantly impact the performance here.
No debug information impacts on size, while O2 compile parameter too.
O3 and other architecture flags can enable generation of faster code.
>> The thing is that JRuby requires several things:
>> JRE for running it.
>> JDK for extending it from Java.
>> Also with it's drawbacks:
>> Has no native support for extensions, so Hpricot, nokogiri,
>> RubyInline, ParseTree and many others end with problems.
>> Pretty much current Ruby for Windows situation, anyway :-D
> True. :-)
> Java has had this indifference to native code and it is one of the things
> JRuby seems intent to change on it. For instance, JRuby seems to be
> making use of FFI which enables access to C.
Well, work on ruby-ffi can now be started, but will happen after
One-Click Installer, cannot commit free time to it when upcoming 1.9.1
release is close :-)
>> The dependency in a 12 years old compiler (VC6) has made the
>> development and compilation of gems on Windows a real problem.
>> The goal of using MinGW is not beat VC6 speed (which is a desire) but
>> instead ease the integration path between platforms.
> As far as I have experienced it, MinGW seems to be competitive enough
> with VC for Ruby in terms of producing Ruby interpreters that are fast. Although
> I don't have a thorough study on that at all, so take it with a grain
> of salt. :-)
Is not only about speed, while could be a point. The main goal is
reduce the burden across platforms.
For example, I was really annoyed by "gem.bat" vs "gem" when doing
system calls... we got that fixed into Ruby, so no more conditionals
to take care:
Check less quirk for us section.
>> JRuby, like IronRuby adds another layer of compatibility concerns both
>> developers and users should take in consideration.
> JRuby and IronRuby will appeal to new users who might not have given Ruby
> a try otherwise. Also, they provide for different deployment opportunities,
> and in doing so, might steal pure Ruby users. :-)
>> Don't forget to include Rubinius in the mix. :-D
> Rubinius is more vaporware than the others. But I have it as a git repository
> mirror alongside the other Ruby implementations to keep an eye on it.
vaporware or not, FFI stuff came out from it :-)
Other concepts like mvm (multi vm branch in ruby source) where
inspired by Rubinius mvm actors and inter-vm communication.
>>> See an example of IronRuby:
>>> What worries me is Ruby having its ass kicked by these other implementations
>>> mainly on Windows. I personally think it's just easier to run JRuby on Windows
>>> and in the name of reaching a consensus, JRuby could win as my preferred
>>> platform, at least until Microsoft adopts the GNU tools or .NET + Mono
>>> with IronRuby give Java and JRuby something to worry about.
>> In some way I agree with your statement, but I don't feel in that way.
>> As I mentioned previously, neither JRuby or IronRuby will be able to
>> work with a huge number of gems that require native extensions.
>> In case there is no binding for the library neither in Java or dotNet,
>> then the users should decide for other libraries or switch back to
> In the case of both Java and .NET, using Ruby as a frontend, it
> becomes even less than a deal to create wrappers in Ruby for
> the libraries in those languages than it has been in Ruby with C
> and C++. It's just a question of making Ruby scale to handle
> potentially thousands of files in those platforms in a fast enough
> way. :-)
>> The goal of One-Click Installer is ease the path, integrating GNU
>> tools and documenting the whole process which has been, until now,
>> close managed by the guys at garbagecollect for their "binary
>> Even more, I will not doubt on creating a One-Click JRuby/IronRuby
>> Installer in the future, only if people is interested.
> I figure it would have been important for the Ruby Installer to support
> even the development versions of Ruby so it could become a reference
> and in doing so evolve beyond imagination. :-)
That's one of the things we are working on, but not yet for prime time ;-)
Stay tuned :-)
Thanks to you Joao!
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
More information about the Rubyinstaller-devel