[Rubyinstaller-devel] Yet another Windows installer

Luis Lavena luislavena at gmail.com
Fri Mar 21 18:04:10 EDT 2008

Welcome Michal!

On Fri, Mar 21, 2008 at 3:49 PM, Michal Suchanek <hramrach at centrum.cz> wrote:
> On 21/03/2008, Luis Lavena <luislavena at gmail.com> wrote:
>  > On Mar 20, 5:52 pm, Michal Suchanek <hramr... at centrum.cz> wrote:
>  >  >
>  >  > Well, I consider myself sort of developer but I haven't used Rake so far.
>  >  >
>  >
>  >
>  > I'm just used to do every repetitive task with Rake and I think other
>  >  developers will agree.
>  There are also other alternatives like make, shell scripts, etc.
>  And it does not help with the repetitiveness of the download that much
>  as there are the timeouts. I do not quite understand how the stuff
>  fits together but I suspect these are somewhere in the rake itself so
>  perhaps rake needs a retry option for downloads.

Well, the ideas, as I said: use the most ruby you could possible use,
that means use Ruby to build ruby :-)

There is no shell script that could perform what are we doing right
now without external tools for download and unpack (yes, Is a bummer
have zlib1.dll around, will try to fix this weekend).

If you have used the garbagagecollect builds for your "Yet another
Ruby Installer for Windows", then you know there is no documentation
or way to recreate the process locally, and thus there is no way to
simple fix the problems the current Ruby for Windows faces.

Then you're stuck each time to the releases made by somebody else and
reply lots of tickets and support request when things don't work out
of the box, like WIN32OLE in 1.8.6-p110 (which was replaced soon
enough by p111)... I think you get the picture.

Instead of gargabecollect release, I'm not using Visual C as compiler,
since is not available anymore, and couldn't be freely obtained like
MinGW (there is also the lack of good speed we got from MinGW build).

This compilation of recipes try to get MinGW+MSYS tools to fully build
Ruby without you prior requiring nothing more than a working Ruby
installation. So there is no manual setup of MinGW or something

>  >  > I do not get a download timeout or it is quite well obfuscated at
>  >  > least. I get slow download of packages one after another and then I
>  >  > get something like:
>  >  >
>  >  > execution timed out
>  >  > rake aborted
>  >  >
>  >
>  >
>  > The error message you get can vary, that depends on the sourceforge
>  >  mirror you got. sorry about that.
>  >
>  >  The idea is that you don't need to download the sources package again
>  >  unless you 'clobber' or nuke your downloads directory (rake clean will
>  >  only clean the sandbox)
>  Good, but if you unpack a fresh copy of the installer the downloads
>  aren't there unless you save them and put them into the fresh copy
>  manually.

Hmm, don't understand what are you saying, let me explain how I
designed this in the first place.

1) after you unpack latest.zip (I actually name the folder
installer3.dev, anyway) you jump in and perform the 'rake download'

This is the first and only time you require to do so, since that task
will download all the zip, tar.bz and tar.gz files to build a clean
ruby each time, unless you update some of the required files (version
updates or security fixes, etc).

2) since you start with a clean checkout of the installer, you proceed
to "extract" and "prepare", which will create the required directories
in sandbox and unpack all the tools. Then it arrange (prepare) some of
the files and dlls to proceed with the next step.

This is required every time you "clean" your sandbox (that means when
you change something in the recipes and want to do a fresh start).

3) configure task actually run the GNU autoconf script that is bundled
with ruby, and generate the proper config file and the makefile
required by the compile task.

4) compile will try (at this time) to build ruby with the bindings
that extract and prepare made available, at this time, only "zlib" and
"readline" are in place.

5) Install task emulates the directory structure the garbage collect
distribution have (is a ruby installation).

The idea is later in the process rubygems gets installed over there,
but there are no recipes for it right now.

6) check task will ensure that everything built in the compile task
works out of the box. It runs the ruby test units to garantee that.

Since readline is failing, I didn't proceed to work on the MSI
installer generators or the RubyGems installation.

>  I still think it would be overall easier to just put a copy of
>  zlib1.dll into the extract_tools folder.

Is a bad practice add binaries to your repository... doing that you're
forced to keep it updated from release to release...

I'll fix the extract utils to expand the downloaded zlib package.

>  >
>  >
>  >  > Yes, I tried some tasks until I was sure there's nothing that does not
>  >  > produce any error but it might be that executing the tasks out of
>  >  > order leaves some fallout.
>  >  >
>  >
>  >
>  > To make you happy: the Rakefile now have a defaults (recipes/
>  >  defaults.rake) that:
>  >
>  >  download,
>  >  extract,
>  >  prepare,
>  >  configure,
>  >  compile and
>  >  install
>  Very nice, now running rake gives me a ruby build :-)
>  However, it would be nice if this copy also included rubygems and/or
>  rake so that rebuilding with this copy new was easier. To rebuild I
>  had to
>  - download rubygems
>  - run the extract process of the installer so that I got bsdtar
>  - extract rubygems
>  - in rubygems run setup.rb configure (this for some reason performed
>  the installation already)
>  - run gem install rake

As explain above, RubyGems is not my main focus right now, but get a
stable working ruby build instead (there are lot of extensions don't
build right now, like iconv, curses and others).

However, if you want it included right now, I think a rubygems recipe
can be added to dependencies, and download, extract and install tasks

>  After this I could nuke the install3 folder, extract a new one, and
>  build ruby with the newly installed ruby.

That's part of the idea, but how you nuke installer3? just use rake
clean to erase the sandbox, don't stress the servers doing several
downloads (clean will not remove the downloads, clobber or a new
checkout will).

>  Thanks

Luis Lavena
Multimedia systems
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.
Douglas Adams

More information about the Rubyinstaller-devel mailing list