autoconf for ruby

[saiph]

hi list,

are there any ruby bindings for autoconf?
i'm looking for macros, docs and examples in order to
learn to install ruby programs using only the standard gnu
procedure ./configure, make && make install

thank you.



--

here are more things in heaven and earth,

horatio, than are dreamt of in your philosophy.

 

[Nikolai Weibull]

--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

are there any ruby bindings for autoconf?

Here's something I wrote, based on Vim's configure.in, that checks for a
ruby interpreter. It's usable (hopefully) when wanting to embedd ruby.
Otherwise, you simple use an extconf.rb and perhaps setup.rb,
nikolai

--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ruby.m4"

define(arch-tag)
# arch-tag: 1d925bca-9669-4b16-93da-c88de10bca59
dnl contents: Ruby related macros.
dnl
dnl Copyright (C) 2004 Nikolai Weibull <[email protected]>
dnl
dnl This program is free software; you can redistribute it and/or modify
dnl it under the terms of the GNU General Public License as published by
dnl the Free Software Foundation; either version 2 of the License, or
dnl (at your option) any later version.
dnl
dnl This program is distributed in the hope that it will be useful,
dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
dnl GNU General Public License for more details.
dnl
dnl You should have received a copy of the GNU General Public License
dnl along with this program; if not, write to the Free Software
dnl Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA



AC_DEFUN([CHECK_LIB_RUBY],
[
AC_PATH_PROG([cv_path_ruby], [ruby])
if test "x$cv_path_ruby" != x; then
AC_MSG_CHECKING([for ruby version >= $1])
if $cv_path_ruby -e 'VERSION >= "$1" or exit 1' >/dev/null 2>/dev/null;then
cv_ruby_version=`$cv_path_ruby -e 'print VERSION'`
AC_MSG_RESULT([$cv_ruby_version])
rubyhdrdir=`$cv_path_ruby -r mkmf -e 'print Config::CONFIG[["archdir"]]'\
|| echo $hdrdir`
RUBY_CFLAGS="-I$rubyhdrdir"

rubylibs=`$cv_path_ruby -r rbconfig -e 'print Config::CONFIG[["LIBS"]]'`
if test "x$rubylibs" != x; then
RUBY_LIBS="$rubylibs"
fi

librubyarg=`$cv_path_ruby -r rbconfig -e 'print \
Config.expand(Config::CONFIG[["LIBRUBYARG"]])'`
if test -f "$rubyhdrdir/$librubyarg"; then
librubyarg="$rubyhdrdir/$librubyarg"
else
librubyarg=`$cv_path_ruby -r rbconfig -e "print \
'$librubyarg'.gsub(/-L\./, %'-L#{ \
Config.expand(Config::CONFIG[[\"libdir\"]])}')"`
fi
if test "x$librubyarg" != x; then
RUBY_LIBS="$librubyarg $RUBY_LIBS"
fi

rubyldflags=`$cv_path_ruby -r rbconfig -e 'print \
Config::CONFIG[["LDFLAGS"]]'`
if test "x$rubyldflags" != x; then
LDFLAGS="$rubyldflags $LDFLAGS"
fi
else
AC_MSG_RESULT([too old; need Ruby version $1 or newer])
fi
fi

AC_SUBST([RUBY_CFLAGS])
AC_SUBST([RUBY_LIBS])
])



dnl vim: set sts=2 sw=2:

--SUOF0GtieIMvvwua--

 

[Brian Candler]

are there any ruby bindings for autoconf?
i'm looking for macros, docs and examples in order to
learn to install ruby programs using only the standard gnu
procedure ./configure, make && make install

I know this doesn't answer your question directly, but there are several
much better options than using gnu autoconf for installing ruby programs.

(1) mkmf.rb

This does the same sort of thing as autoconf, but it's written in Ruby, and
comes as standard with your Ruby installation.

There are some examples (of using it to build C extensions to Ruby) at
http://www.rubycentral.com/book/ext_ruby.html

(2) setup.rb

The long-standing and venerable install script, which you can include in
your Ruby library or application tarball.
http://www.loveruby.net/en/prog/setup.html

It works very similar to autoconf:
ruby setup.rb config --prefix=/opt/foo
ruby setup.rb setup
ruby setup.rb install

(3) gems

gems is a new and flexible way of packaging Ruby libraries and
applications, allowing users to install them directly off the 'net and
taking care of dependencies automatically.
http://rubygems.rubyforge.org/wiki/wiki.pl
http://www.pragmaticprogrammer.com/titles/ruby/gems.pdf

Regards,

Brian.

 

[saiph]

Thank you!

it's what i'm looking for.

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

..and a good template for Makefile.am.

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.

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


regards.


--

here are more things in heaven and earth,

horatio, than are dreamt of in your philosophy.

 

[Nikolai Weibull]

i need also something to test a generic lib.

Hm, dunno how to do that in a good way.

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.

Too bad that they suck so hard,
nikolai

 

[Eivind Eklund]

are there any ruby bindings for autoconf?
i'm looking for macros, docs and examples in order to
learn to install ruby programs using only the standard gnu
procedure ./configure, make && make install

Please let me chime in on the side of cutting the head off autotools.

They DO NOT WORK.

If you have to support the ./configure, make a file named "configure"
with your completely own code. You can find ruby by using
#!/usr/bin/env ruby.


On the autotools and my experience with them:

In their present incarnation, they make porting harder than it was
when hand-porting in 1990 when they were first introduced, and the
underlying porting landscape was much, much worse then than it was
now.

Autotools turn nice Unix machines into Windows machines - either they
work at once, or you get an error message that is effectively
impossible to determine anything from.

The autotools use sh and Makefiles as the target language for a
compiler. This is a horrible idea. Almost half a lifetime ago, I
used to crack copy protection for computer games as a hobby. These
were released as binary only, with whatever tricks the programmer
could throw in to make it harder to remove the copy protection.
Cracking copy protection that was intentionally made hard to deal with
was an order of magnitude EASIER than fixing autoconf problems.

Propagating this evil into Ruby just because it is "standard" is a
bad, bad idea.

Eivind.

 

[Steven Jenkins]

Please let me chime in on the side of cutting the head off autotools.

They DO NOT WORK.

This is a little harsh. You may have issues, as I do, with the usability
of autotools. They may not be right for this application. But they do
work, and there are literally thousands of packages that attest to it.

Steve

 

[Aredridel]

This is a little harsh. You may have issues, as I do, with the usability

of autotools. They may not be right for this application. But they do
work, and there are literally thousands of packages that attest to it.

Yup.

The worst part is that they're hard to understand; however, there's
not much to be done about it and still run on a system with nothing
but a posix shell and a C compiler.

 

[Eivind Eklund]

Let me just state that the main point here is that it is better to
leave the horror of portability to the interpreter level, and avoid
autoconf et al when you've already got Ruby installed anyway.

The below is just information regarding autotools and the fact that
there actually existed a (in many ways better) porting world before
autotools, and hopefully will exist a better world again after them.

This is a little harsh. You may have issues, as I do, with the usability
of autotools. They may not be right for this application. But they do
work, and there are literally thousands of packages that attest to it.

The design goal of the autotools was to make porting easier. When, in
practice, for the packages I've had to deal with, porting has been
harder than it was before the introduction of autotools (and at that
point there were more differences to deal with), I feel that I'm
justified in saying that they do not work.

The worst part is that they're hard to understand; however, there's
not much to be done about it and still run on a system with nothing
but a posix shell and a C compiler.

This is plain incorrect. It was much, much easier to understand
configure scripts etc before the introduction of autotools. The
problem is that sh is a horrible target language for a compiler, and
M4 is a horrible implementation language for a compiler.

Sure, the problem space is icky, but it is not anywhere near as icky
as autotools make it. We had experience with this before autotools,
and that was a trifle harder on the packager, and easier on the person
doing porting - problems were usually fairly straightforward to
resolve.

This changed (IIRC) somewhere in the 1994-1997 timeframe with the
widespread adoption of autoconf.

Eivind.

 

[Aredridel]

This is plain incorrect. It was much, much easier to understand

configure scripts etc before the introduction of autotools. The
problem is that sh is a horrible target language for a compiler, and
M4 is a horrible implementation language for a compiler.

Yeah, it's a nasty space where you can't guarantee any tools but sh
and C. It's not a fun place to start your bootstrapping -- I'm glad
that Ruby has mkmf.rb, and extconf.rb -- for the domain of
systems-already-with-Ruby, it's far better than configure.

 

[vruz]

This is plain incorrect. It was much, much easier to understand

Yeah, it's a nasty space where you can't guarantee any tools but sh
and C. It's not a fun place to start your bootstrapping -- I'm glad
that Ruby has mkmf.rb, and extconf.rb -- for the domain of
systems-already-with-Ruby, it's far better than configure.

From 'the goat book' on 'autotools'
http://sources.redhat.com/autobook/autobook/autobook_191.html#SEC191

 

[Aredridel]

From 'the goat book' on 'autotools'

http://sources.redhat.com/autobook/autobook/autobook_191.html#SEC191

Heartily agreed. M4 is ugly.