Ruby's build system

right now autotools, make and shell scripts are used to build ruby.

i saw that yarv needs a version of ruby to be present in order to
build it: right?
(i dont know if this is a temporary dependency)

but if ruby is needed to build ruby, we might aswell use a ruby
buildsystem like rake or rant for building ruby?

this would clearly have some disadvantages (difficulty of build ruby
for a platform that has no ruby binaries yet), but it would be eating
our own dog food though.

just looking for some feedback.
cies breijs.

On 10/29/06, cies [email protected] wrote:

for a platform that has no ruby binaries yet), but it would be eating
our own dog food though.

just looking for some feedback.
cies breijs.

There was interest at RubyConf in converting the Ruby build system to
use mkrf (Kevin C.'s new replacement for mkmf, which needs a new
name, IMO).

In order for this to be possible, we need to make sure that ‘rake’
itself runs under miniruby.

cies wrote:

this would clearly have some disadvantages (difficulty of build ruby
for a platform that has no ruby binaries yet), but it would be eating
our own dog food though.

Selfhosting is a nice exercise in brain self-surgery, but I think it’s
more practical to bootstrap using an external environment that’s most
likely to be present. I’m not sure I’d like the ruby build process to
take too much time building a bloated miniruby just to build itself
again for no practical benefit whatsoever.

David V.

David V. wrote:

Selfhosting is a nice exercise in brain self-surgery, but I think it’s
more practical to bootstrap using an external environment that’s most
likely to be present. I’m not sure I’d like the ruby build process to
take too much time building a bloated miniruby just to build itself
again for no practical benefit whatsoever.

David V.

Yeah, but … “an external environment that’s most likely to be present”
translates to “GNU/Linux/gcc”, doesn’t it? Which means MacOS and Windows
lag. A bootstrap using an existing “Pure Ruby” (Ruby plus Rake plus
RubyGems, etc.) makes a lot more sense.

On 10/29/06, David V. [email protected] wrote:

again for no practical benefit whatsoever.

It already builds a miniruby that can probably run rake. This would
just extend the already self-hosting Ruby build process to the earlier
possible point in the chain.

M. Edward (Ed) Borasky wrote:

translates to “GNU/Linux/gcc”, doesn’t it? Which means MacOS and Windows
lag. A bootstrap using an existing “Pure Ruby” (Ruby plus Rake plus
RubyGems, etc.) makes a lot more sense.

Short of implementing a C compiler in Ruby (I give it a month or two
before someone announces a 0.0.1 version of that), those requirements
aren’t going away - you still have to shell out to a C compiler, which
is by far where most build system porting problems lurk (compiler switch
semantics, different shell escaping, directory names with spaces innem.)

I guess the original poster’s point was porting the build environment to
Ruby, which, while removing a dependency some people don’t have (A POSIX
build environment), would introduce a dependency most people that want a
ruby interpreter don’t have (a ruby interpreter).

You’d need -some- form or Ruby to bootstrap (a precompiled miniruby
perhaps), and if you’re geek enough to want a self-built Ruby on
non-POSIX platforms (e.g. Windows), getting a POSIX environment can’t be
that hard. (I trust you don’t need any hints on that.)

Moving to rake instead of make might be of benefit though if it lets you
get rid of some spaces-in-pathnames woes. (Since you don’t have a string
evaluated by a shell at umpty barely predictable spots, something for
which I’d like to stab people responsible for Unix shells into
vulnerable places with plastic forks many times.) But it’s still not
going all away yet, e.g. the autotools remain. I just don’t see a full
rewrite both coming anytime soon, and since I doubt one would be doable
without more or less a full Ruby install, I don’t see much benefit as
opposed to just going as far as you can push the (presumably trivial to
build) miniruby.

David V.

so conclusion:

shipping rake.rb with the ruby source, and using it rake as build
system. this would force us to ship ready made scripts for building
miniruby first (to bootstrap in case no ruby is found on the machine)
– so rake can be executed using miniruby.

pro’s:

  • ditch autoconf and make (and the problems they come with)
  • more self contained
  • probably easier to maintain

con’s:

  • we “need us to ship ready made scripts for building miniruby”, how
    to make these?
  • we have to change (something that is not really broken); i don’t
    know if it counts as a con :wink:

On 10/29/06, cies [email protected] wrote:

so conclusion:

shipping rake.rb with the ruby source, and using it rake as build
system. this would force us to ship ready made scripts for building
miniruby first (to bootstrap in case no ruby is found on the machine)

This is already how it works.