From: Brian Candler <B.Candler@...>
Date: 2004-09-30T00:31:03+09:00
Subject: Re: autoconf for ruby

> i need also something to test a generic lib.
> i.e.:
> 
> AC_PATH_PROG([FTOOL], ftools.rb, [], [$RUBYLIB:/usr/lib/ruby/1.8])
> if test -z $FTOOL; then
>   AC_MSG_ERROR(no ftools.rb library)
> fi 

From this, I guess you want to modify your xxx.rb file so it contains the
correct path to ftools? Normally that's not necessary, you'd just say

  require 'ftools'

or:

  $:.unshift '.'
  require 'ftools'

(Ruby does a run-time search for ftools.rb; it the second case it will first
look in the current directory, and then in the usual places)

I'd say it's the Ruby Way[TM] to let the user install the package anyway,
and let it give a runtime error if ftools is not actually available at the
time it is required. The user can then install ftools, in its usual place,
to fix the problem.

If you want your program to behave differently depending on whether or not
ftools is available, then again this can be done at run-time:

  begin
    require 'ftools'
  rescue LoadError
    warn "Certain functionality not available without ftools"
  end

However, if this is the main concern for you, then the way Gems handles
libraries is probably of interest. You can even have multiple versions of
the same library installed; Gems puts each version in a different directory,
and finds and loads the requested one for your application. And instead of
just giving an error at install time, it can go and fetch and install the
required library automatically.

> i prefer the idea to use gnu tools to setup.rb or mkmf library because
> they are allready a standard de facto for gnu/linux systems,
> the maintanance would be simpler and it can expand ruby
> language usage.

But you are talking about installing *Ruby* packages are you not? In which
case, you know that Ruby is already installed on the system. This means you
can rely on mkmf being there, and also include setup.rb in your package.
This is really no different to including "configure" in your package; one is
a Ruby script, the other is a shell script.

GNU autoconf is, at the end of the day, a hacked-together bunch of shell
scripts and m4 macros. It's done that way because a Bourne-like shell is
probably the lowest common denominator you can expect on a system. But once
you know there's a decent scripting language like Ruby on your system, it
makes a lot of sense to install further Ruby components using Ruby. It's
much cleaner and easier to maintain.

You'll find the same with Perl modules in CPAN: the typical installation is
   perl Makefile.PL
   make
   make install

> much more automake supports, in opposition to setup.rb,
> the unistall option too.

Good point. If that's important then I'd go with Gems again.

Regards,

Brian.