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.
* saiph <order@intrage.it> [Sep 28, 2004 23:01]:
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
ruby.m4 (2.36 KB)
--
::: 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);}
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.
On Wed, Sep 29, 2004 at 04:34:18AM +0900, saiph wrote:
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.
On Wed, 29 Sep 2004 04:34:18 +0900, saiph <order@intrage.it> wrote:
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!
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.
Eivind Eklund wrote:
On Wed, 29 Sep 2004 04:34:18 +0900, saiph <order@intrage.it> wrote:
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 installPlease 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
* saiph <order@intrage.it> [Sep 29, 2004 15:30]:
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
--
::: 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);}
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.
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.
Eivind Eklund wrote:
> 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.
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.
Aredridel wrote:
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.
On Fri, 1 Oct 2004 01:37:39 +0900, Steven Jenkins <steven.jenkins@ieee.org> wrote:
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.
> 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.
From 'the goat book' on 'autotools'
http://sources.redhat.com/autobook/autobook/autobook_191.html#SEC191
--
--- vruz
From 'the goat book' on 'autotools'
http://sources.redhat.com/autobook/autobook/autobook_191.html#SEC191
Heartily agreed. M4 is ugly.