Autoconf for ruby

ruby-talk
1

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.

2

~/tmp > find
   ./lib
   ./lib/a.rb
   ./setup.rb

   ~/tmp > for op in config setup install;do ruby setup.rb $op || sudo ruby setup.rb $op;done
   ---> lib
   <--- lib
   ---> lib
   <--- lib
   ---> lib
   mkdir -p /usr/local/lib/ruby/site_ruby/1.8/
   install a.rb /usr/local/lib/ruby/site_ruby/1.8/
   Permission denied - /usr/local/lib/ruby/site_ruby/1.8/a.rb
   Try 'ruby setup.rb --help' for detailed usage.
   Password:
   ---> lib
   mkdir -p /usr/local/lib/ruby/site_ruby/1.8/
   install a.rb /usr/local/lib/ruby/site_ruby/1.8/
   <--- lib

   ~/tmp > cat InstalledFiles
   /usr/local/lib/ruby/site_ruby/1.8/a.rb

   ~/tmp > sudo rm -rf `cat InstalledFiles`

doesn't get much easier than that.

on another note - one thing to consider is that mkmf, setup.rb, install.rb, or
whatever tend to be much more stable than the autotools which, almost by
definition, must continually evolve to support every /bin/sh shell on every
system out there. a ruby based install (which brian correctly pointed out as
known to be effective since ruby would already be installed) is going to vary
ALOT less since the set of interpreters it has to run under is much less.
take install.rb for example, it hasn't changed since i started using ruby and
works with 1.6.x, 1.8.x, probably even others on *nix, windows, etc. it's
also only about 100 lines long. autotools does not work on windows.

-a

···

On Thu, 30 Sep 2004, Brian Candler wrote:

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.

--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen

===============================================================================

3

Too bad that they suck so hard

i'm a beginner, and i agree with Ara when he says:

must continually evolve to support every /bin/sh shell

or better freeze because the compatibility is, as i see,
grant to obsolete systems.

a solution might be to use a bash modern synopsys to write autoconf macro
considering compatibility in a pragmatic way?!

however what are the other relavant reasons that do them suck?

autotools does not work on windows.

projects i've in mind are strictly for linux.
for windows, of course, won't be a reasonable thought.

~/tmp > for op in config setup install;do ruby setup.rb $op || sudo ruby

setup.rb $op;done

this is the best solution for a developer but from the user point of view
reading the setup.rb manual to know options and behaviour is a pure waste of
time.

it can be unhappy to know after 5min that another ruby project he want to
test uses gem.

so, imo, the relax of configure && make && sudo make install
can help the spread of a software in unix env. is it true?

the promblem is that many sys-adm are even to lazy to install an interpreter,
in general when even valid people see something of new is a bit discouraged
because it can be a source of problem or bugs.

···

--

here are more things in heaven and earth,

horatio, than are dreamt of in your philosophy.

4

That's smart. Would be nice to make "ruby setup.rb uninstall" do that
though.

Regards,

Brian.

···

On Thu, Sep 30, 2004 at 01:05:21AM +0900, Ara.T.Howard@noaa.gov wrote:

  ~/tmp > cat InstalledFiles
  /usr/local/lib/ruby/site_ruby/1.8/a.rb

  ~/tmp > sudo rm -rf `cat InstalledFiles`

doesn't get much easier than that.

5

sure seems that way to me too - i always assumed the InstalledFiles list was
an artifact of work in progress that would do just that. on the other hand
the 'extra' step i use isn't a bad safegaurd...

cheers.

-a

···

On Tue, 5 Oct 2004, Brian Candler wrote:

On Thu, Sep 30, 2004 at 01:05:21AM +0900, Ara.T.Howard@noaa.gov wrote:

  ~/tmp > cat InstalledFiles
  /usr/local/lib/ruby/site_ruby/1.8/a.rb

  ~/tmp > sudo rm -rf `cat InstalledFiles`

doesn't get much easier than that.

That's smart. Would be nice to make "ruby setup.rb uninstall" do that
though.

--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen

===============================================================================