Lars Christensen
2008-Aug-15 18:01 UTC
[Rubyinstaller-devel] Working with multiple Ruby versions
Hi, I''d like the option to work with multiple ruby versions in the same rubyinstaller directory, primarily to speed up ''rake'' operations and to avoid multiple downloads, extracts, etc. Also, the current ''cp'' operation on the ruby sources code when checking out from SVN is very slow. My suggestion is to put the source/build/install targets into separate directories, depending on the origin and version of the Ruby source. For example, when pulling from SVN: sandbox/ruby_source/svn/tags/v1_8_6_114 sandbox/ruby_build/svn/tags/v1_8_6_114 sandbox/ruby_mingw/svn/tags/v1_8_6_114 Or a branch: sandbox/ruby_source/svn/branches/ruby_1_8 Or from the tarball: sandbox/ruby_source/ruby-1.8.6-p114 I''ve pushed some changes to http://github.com/larsch/rubyinstaller/commits/nocopycheckout2/ which implements the above. You can set the SVN URL in config/ruby_installer.rb, and it will then decide a path on it''s own, from the contents of the URL. This can still be overridden by setting the options, e.g. :checkout_target, but by default they are left out and generated by the script. Lars
Luis Lavena
2008-Aug-23 07:25 UTC
[Rubyinstaller-devel] Working with multiple Ruby versions
On Fri, Aug 15, 2008 at 8:01 PM, Lars Christensen <larsch at belunktum.dk> wrote:> Hi, >Hey Lars! Sorry took me so long get back to you, kind of hectic lately.> I''d like the option to work with multiple ruby versions in the same > rubyinstaller directory, primarily to speed up ''rake'' operations and to > avoid multiple downloads, extracts, etc. Also, the current ''cp'' operation on > the ruby sources code when checking out from SVN is very slow. >I was thinking that we need to establish a "label" for those different version, and also get rid of the checkout and copy procedure, whcih is suboptimal like you said.> My suggestion is to put the source/build/install targets into separate > directories, depending on the origin and version of the Ruby source. > > For example, when pulling from SVN: > > sandbox/ruby_source/svn/tags/v1_8_6_114 > sandbox/ruby_build/svn/tags/v1_8_6_114 > sandbox/ruby_mingw/svn/tags/v1_8_6_114 > > Or a branch: > > sandbox/ruby_source/svn/branches/ruby_1_8 > > Or from the tarball: > > sandbox/ruby_source/ruby-1.8.6-p114 >Hmn, I was thinking something more in the lines of what multiruby does, but with a twist: sandbox/ruby_{version}/source sandbox/ruby_{tag,branch}/build sandbox/ruby_{tag,branch}/package version can be tag, branch, tarball signatures, like 1_8 (for branch) or 1_8_6_114 for tag and 1.8.6-p114 for tarball. In any case, I''m considering labeling those version as stable, current and candidate for ruby18 and ruby19 ;-)> I''ve pushed some changes to > http://github.com/larsch/rubyinstaller/commits/nocopycheckout2/ which > implements the above. You can set the SVN URL in config/ruby_installer.rb, > and it will then decide a path on it''s own, from the contents of the URL. > This can still be overridden by setting the options, e.g. :checkout_target, > but by default they are left out and generated by the script. >Didn''t had time to take a look, gut I think that config/ruby_installer.rb purpose hit another wall issue. When I first designed it was not ready to handle all this different context, and turned to be smaller for what we are trying to do. I''ve been playing with a rewrite of the task, in the lines of the openssl one, but with another twist. a YAML file that specify a single download, a checkout or series of files (packages) for different versions like stable, current and candidate. Then, a parametrized rake task for ruby18 which always depend on gcc, zlib, openssl versions. Unless you specify, it always build stable. If you want a different version, just say: rake ruby18[candidate] and you can also tweak openssl[current] instead of the stable default. ruby18 is not depending on a specific openssl task, but on also a parametrized one. Maybe is stupid, I know :-P Thanks Lars for presenting those scenarios, will be cool if we have a formal "meeting" to discuss next steps (Gordon, you and me) --- and anyone that want to join us! :-D -- Luis Lavena AREA 17 - 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
Lars Christensen
2008-Aug-24 10:55 UTC
[Rubyinstaller-devel] Working with multiple Ruby versions
On Sat, 23 Aug 2008, Luis Lavena wrote:>> I''d like the option to work with multiple ruby versions in the same >> rubyinstaller directory, primarily to speed up ''rake'' operations and to >> avoid multiple downloads, extracts, etc. Also, the current ''cp'' operation on >> the ruby sources code when checking out from SVN is very slow. >> > > I was thinking that we need to establish a "label" for those different > version, and also get rid of the checkout and copy procedure, whcih is > suboptimal like you said.> sandbox/ruby_{version}/source > sandbox/ruby_{tag,branch}/build > sandbox/ruby_{tag,branch}/packageThat appears more clean to me. I''ll update my approach.> version can be tag, branch, tarball signatures, like 1_8 (for branch) > or 1_8_6_114 for tag and 1.8.6-p114 for tarball. > > Didn''t had time to take a look, gut I think that > config/ruby_installer.rb purpose hit another wall issue. When I first > designed it was not ready to handle all this different context, and > turned to be smaller for what we are trying to do.Yes, it does seem abit awkward. Some parameters can be derived from others, such as paths from SVN urls etc. That is not so clean when creating OpenStructs.> I''ve been playing with a rewrite of the task, in the lines of the > openssl one, but with another twist. > > a YAML file that specify a single download, a checkout or series of > files (packages) for different versions like stable, current and > candidate. > > Then, a parametrized rake task for ruby18 which always depend on gcc, > zlib, openssl versions. Unless you specify, it always build stable. > > If you want a different version, just say: rake ruby18[candidate] and > you can also tweak openssl[current] instead of the stable default.Is the [] syntax something from Rake?> Thanks Lars for presenting those scenarios, will be cool if we have a > formal "meeting" to discuss next steps (Gordon, you and me) --- and > anyone that want to join us! :-DSure. What form? Lars