Package, a future replacement for setup.rb and mkmf.rb

ruby

    Sponsored Links

    Next

  • 1. How do I install sqlite3 on Windows, no really!?
    Before someone comes in and says "this has been covered before," I know people _think_ that it has been covered before but that isn't helping me now. People have been saying that all you have to do is use the previous version like so: gem install sqlite3-ruby -v=1.2.3 ...however, this isn't working for me. The error I get... is exactly the same error you would get if you didn't bother specifying a version number. It looks like this is not the right syntax since it tries to install 1.2.4. However, I can't for the life of me figure out what the correct syntax for this command is 'cause every combination I've tried does exactly the same thing! So, how do I install this crazy thing on Windows, no really?! Thank you...

Package, a future replacement for setup.rb and mkmf.rb

Postby Christian Neukirchen » Mon, 06 Jun 2005 07:59:15 GMT

Hello,

During a discussion on IRC, I started to wonder if Ruby's install
scripts are state of the art, what could be done better and how.

Ruby's mkmf.rb and Aoki's setup.rb probably have their roots in the
oldest pieces of Ruby source still in use. While setup.rb had some
changes in the latter time, mkmf.rb more or less stayed the same.

I have looked into how other languages install source and compile
extensions, and the library I liked best so far is Python's distutils.
I'm not very familiar with Python, but I like the general approach and
the essence of API. Basically, you create a file, setup.py, like
this:

from distutils.core import setup

setup (name = "Distutils",
version = "0.1.1",
description = "Python Module Distribution Utilities",
author = "Greg Ward",
author_email = " XXXX@XXXXX.COM ",
url = "http://www.python.org/sigs/distutils-sig/",

packages = ['distutils', 'distutils.command'])

In Ruby, this would maybe look like that:

require 'package'

setup {
name "Distutils"
version "0.1.1"
description "Python Module Distribution Utilities"
author "Greg Ward"
author_email " XXXX@XXXXX.COM "
url "http://www.python.org/sigs/distutils-sig/"

packages ['distutils', 'distutils/command']
}

Given this file, we can simply run:

python setup.py install

and the files will get installed where they belong to. distutils can
also handle different prefixes, installing into home directories, and
complex cases like putting scripts to /usr/bin, but libraries to
/opt/local and whatever.

Python's distutils also handles compiling extensions:

name = 'DateTime.mxDateTime.mxDateTime'
src = 'mxDateTime/mxDateTime.c'
setup (
...
ext_modules =
[(name,
{ 'sources': [src]
'include_dirs': ['mxDateTime'] }
)]
)

Here, something like this would be possible in Ruby (I'm not yet sure
about exact semantics of the Python version):

setup {
# ...
extension("DateTime/mxDateTime/mxDateTime") {
sources "mxDateTime/mxDateTime.c"
include_dirs "mxDateTime"
}
}

Of course, more complex build descriptions can be represented too:

extension("foolib") {
sources "foo.c", "bar.c"
if have_library("foo", "fooble")
define "HAVE_FOO_H"
cflags << `foo-config --cflags`
ldflags << `foo-config --libs`
else
fail "foolib is needed"
end
}

Whether this will generate a Makefile (like mkmf.rb), a Rakefile
or compile directly (like distutils) is still an open question.

To allow for an easy conversion of setup.rb usage, Package will
provide convenience methods that will make it behave like setup.rb
with respect to the directory structure.

Package doesn't try to conquer the world, however, it aims to be just
a tool that would be useful if it was standard and everyone could
build on due to it's policy-neutrality

What advantages will Package have over setup.rb and mkmf.rb, as
they are now?

* simple, clean and consistent working
* unified library to handle both extensions and libraries
* lightweight approach (if included in the standard library)
* easy adaption
* more flexible directory layout: especially small projects
profit from this, as setup.rb's directory layout is quite
bulky by default and not very customizable
* easier packaging by third-party p

Re: Package, a future replacement for setup.rb and mkmf.rb

Postby Austin Ziegler » Mon, 06 Jun 2005 08:15:15 GMT



I think that there is room for improvement, definitely. However, if
you're going to do extension support with this, it absolutely *must*
work perfectly well on Windows. It has to work better than setup.rb,
and setup.rb works mostly well for that. Gems, much less so.

-austin
-- 
Austin Ziegler *  XXXX@XXXXX.COM 
               * Alternate:  XXXX@XXXXX.COM 



Re: Package, a future replacement for setup.rb and mkmf.rb

Postby Jim Freeze » Mon, 06 Jun 2005 08:42:40 GMT

* Christian Neukirchen < XXXX@XXXXX.COM > [2005-06-05 07:59:15 +0900]:


If you have #name(arg) do the same thing as #name=(arg), how
does one get access to the instance variable?



I find mkmf.rb very useful to create a Makefile when I am building a C wrapper
to some library. Will Package do the same thing, or will mkmf still
be needed?

-- 
Jim Freeze
Theory and practice are the same, in theory. -- Ryan Davis



Re: Package, a future replacement for setup.rb and mkmf.rb

Postby ES » Mon, 06 Jun 2005 09:22:50 GMT

e 4/6/2005, "Christian Neukirchen" < XXXX@XXXXX.COM > a rit:

No. setup.rb is OK but inflexible. Package management (gems etc.)
nor build management (Rant, Rake) should not be in any way incorporated
in 'Package', either.

Might be a good idea to have the extension builder as a completely
separate tool, too.

Just a simple, easy packager/setup utility, please!
(I will help, too, if I can!)



E

template<typename duck>
void quack(duck& d) { d.quack(); }



Re: Package, a future replacement for setup.rb and mkmf.rb

Postby Charles Steinman » Mon, 06 Jun 2005 11:39:26 GMT



That isn't too hard to implement.

def variable(*args)
  @variable = args.first unless args.empty?
  @variable
end

Now we can be even more like Smalltalk!

Seriously, though, I think a Hash would both make more sense there (if
I understand correctly what it's doing) and be more Ruby-like than
hacking the setter syntax in a block. Though I guess maybe people don't
like typing equals signs. I don't know.


Re: Package, a future replacement for setup.rb and mkmf.rb

Postby dave » Mon, 06 Jun 2005 14:48:39 GMT


clap, clap.
this is wonderfull: we need it.



I can suggest you to look at scons ( http://www.**--****.com/ )


A great thing would be to replace: 
  - configure make and make install

As said on this mailing list to rake author you could:


work on a configure script template like configure.in.

and provide macro as ruby functions like:

?- Ac.init_automake("package", 1.0.1)


and Makefile.am that generate a Makefile.in and and a Makefile.rb

  - Am.subdirs(src)
  - Am.sources("package", [files])


This approach will led you to a great success, imo.




-- 
horatio, than are dreamt of in your philosophy.



Re: Package, a future replacement for setup.rb and mkmf.rb

Postby Christian Neukirchen » Mon, 06 Jun 2005 17:46:32 GMT

Austin Ziegler < XXXX@XXXXX.COM > writes:




I don't think making the installer work on windows "perfectly" would
be a hard job.  For building extensions, things look a bit
different...  I'd certainly need a win32 expert for that.

How well does extconf.rb work on win32?

-- 
Christian Neukirchen  < XXXX@XXXXX.COM >   http://www.**--****.com/ 



Re: Package, a future replacement for setup.rb and mkmf.rb

Postby Christian Neukirchen » Mon, 06 Jun 2005 17:48:46 GMT

Jim Freeze < XXXX@XXXXX.COM > writes:


Package will try to provide a more clean (no icky globals, for
example) API for the things mkmf.rb does.  I think I'll start with a
recent mkmf.rb and refactor it heavily.

-- 
Christian Neukirchen  < XXXX@XXXXX.COM >   http://www.**--****.com/ 



Re: Package, a future replacement for setup.rb and mkmf.rb

Postby Stefan Lang » Mon, 06 Jun 2005 17:49:10 GMT



SCons is a full blown build tool. AFAIK they use the distutils
(setup.py) package for SCons installation.

Stefan




Re: Package, a future replacement for setup.rb and mkmf.rb

Postby Christian Neukirchen » Mon, 06 Jun 2005 17:56:01 GMT

ES < XXXX@XXXXX.COM > writes:


Package will not handle dependencies on it's own (You are strongly
recommended to check for libraries in the build part, though).

Package will not provide general "build management", but does generate
instructions how to build extensions.  That is, if you before used an
extconf.rb, you'll use Package, if you used a custom Rakefile, you'll
continue to do so.

It would be imaginable that Package could generate Rake tasks
dynamically, however, Rake is not (yet?) included in the Ruby standard
library.


I'll try to make it easy to use outside of Package.


Thank you, I'll come back on that.

-- 
Christian Neukirchen  < XXXX@XXXXX.COM >   http://www.**--****.com/ 



Re: Package, a future replacement for setup.rb and mkmf.rb

Postby Christian Neukirchen » Mon, 06 Jun 2005 17:59:01 GMT

dave < XXXX@XXXXX.COM > writes:


Please note that Package aims to specifically help Ruby developers
installing *Ruby* libraries and extensions.  Package is not trying to
be a general purpose tool for other languages, especially not autoconf
or automake.


How about you write the autotools in Ruby and have your own great
success? :-)

-- 
Christian Neukirchen  < XXXX@XXXXX.COM >   http://www.**--****.com/ 



Re: Package, a future replacement for setup.rb and mkmf.rb

Postby Stefan Lang » Mon, 06 Jun 2005 17:59:20 GMT


+0900]:

A clean API sounds good, it would be nice if it could be used as a
library to allow easy integration into other tools, e.g. Rant.
OTOH if Package uses Rant or Rake it is easier to make it portable
and there would be less dependencies on external (non-Ruby) tools.

Stefan



Re: Package, a future replacement for setup.rb and mkmf.rb

Postby Christian Neukirchen » Mon, 06 Jun 2005 18:15:10 GMT

Stefan Lang < XXXX@XXXXX.COM > writes:




I agree.  However, Package should not have any dependencies that are
not in the Ruby standard libraries.

-- 
Christian Neukirchen  < XXXX@XXXXX.COM >   http://www.**--****.com/ 



Re: Package, a future replacement for setup.rb and mkmf.rb

Postby dave » Mon, 06 Jun 2005 18:19:27 GMT

i'm not able to accomplish such glourious task :(


-- 
horatio, than are dreamt of in your philosophy.



Re: Package, a future replacement for setup.rb and mkmf.rb

Postby Lothar Scholz » Mon, 06 Jun 2005 19:28:06 GMT

Hello dave,




d> clap, clap.
d> this is wonderfull: we need it.



d> I can suggest you to look at scons ( http://www.**--****.com/ )


d> A great thing would be to replace: 
d>   - configure make and make install

d> As said on this mailing list to rake author you could:

Sorry but the "autoconf", "automake" and "libtools" are the worst
things i've ever seen in building libraries. I don't think we should
not write even one line to support these 15 year old c library problem
workaround tool.

Use ANSI-C and platform _IF_MY_SYSTEM_ specific precompiler conditions.
If this can't solve your problem change your code or use another
library or restrict the platforms on which your extensions runs.


-- 
 Best regards,                        emailto: scholz at scriptolutions dot com
 Lothar Scholz                         http://www.**--****.com/ 
 CTO Scriptolutions                   Ruby, PHP, Python IDE 's
 




Similar Threads:

1.Using mkmf.rb / extconf.rb and autoconf/automake together

2.[ANN] Ruby Setup 5 (setup.rb)

3.mathn.rb is unacceptably slow (proposed replacements)

In mathn.rb (ruby 1.8.1), Integer#gcd2 and the Prime class are 
unacceptably slow.

(The Integer#gcd2 replacement below is also faster than both Integer#gcd and 
Integer#gcd2 in rational.rb, at least on this machine, and might be a nice 
replacement for Integer#gcd there.)

Try the following test with the standard mathn and then with the method and class 
replacements below it :

require 'mathn'
puts "Finding the GCDs of 10,000 pairs starting at #{Time.now}...."
10000.times { rand(10000).gcd2(rand(10000)) }
puts "Finished with that, now finding the first 10,000 primes at #{Time.now}...."
primes = Prime.new
10000.times { primes.succ }
puts "Finished with that at #{Time.now}...."

Here are replacements for Integer#gcd2 and the Prime class which are effectively 
identical (with Prime.cache and Prime#primes_so_far added), but are thousands of 
times faster for any kind of heavy use :



# Use a Euclidean GCD algorithm
def gcd2(other)
  min, max = [self.abs, other.abs].sort
  min, max = max % min, min while min > 0
  max
end



class Prime
  include Enumerable
  # These are included as class variables to cache them for later uses.  If memory
  #   usage is a problem, they can be put in Prime#initialize as instance variables.

  # There must be no primes between @@primes[-1] and @@next_to_check.
  @@primes = [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67,
71, 73, 79, 83, 89, 97, 101]
  # @@next_to_check % 6 must be 1.  
  @@next_to_check = 103            # @@primes[-1] - @@primes[-1] % 6 + 7
  @@ulticheck_index = 3            # @@primes.index(@@primes.reverse.find {|n|
                                   #   n < Math.sqrt(@@next_to_check) })
  @@ulticheck_next_squared = 121   # @@primes[@@ulticheck_index + 1] ** 2
  
  class << self
    # Return the prime cache.
    def cache
      return @@primes
    end
    alias primes cache
    alias primes_so_far cache
  end
  
  def initialize
    @index = -1
  end
  
  # Return primes given by this instance so far.
  def primes
    return @@primes[0, @index + 1]
  end
  alias primes_so_far primes
  
  def succ
    @index += 1
    while @index >= @@primes.length
      # Only check for prime factors up to the square root of the potential primes,
      #   but without the performance hit of an actual square root calculation.
      if @@next_to_check + 4 > @@ulticheck_next_squared
        @@ulticheck_index += 1
        @@ulticheck_next_squared = @@primes.at(@@ulticheck_index + 1) ** 2
      end
      # Only check numbers congruent to one and five, modulo six. All others
      #   are divisible by two or three.  This also allows us to skip checking against
      #   two and three.
      @@primes.push @@next_to_check if @@primes[2..@@ulticheck_index].find { 
|prime| @@next_to_check % prime == 0 }.nil?
      @@next_to_check += 4
      @@primes.push @@next_to_check if @@primes[2..@@ulticheck_index].find { 
|prime| @@next_to_check % prime == 0 }.nil?
      @@next_to_check += 2 
    end
    return @@primes[@index]
  end
  alias next succ

  def each
    loop do
      yield succ
    end
  end
end



There are other methods from number theory which are a lot faster than mine, but 
these are an easy and quick change with a large speed benefit.  Plus, I don't know 
how to do those ;)




4.lazy.rb 0.9.5 -- transparent futures!

MenTaLguY wrote:

> I'd like to announce a new version of lazy.rb -- this one offering
> thread safety and transparent futures!

Nice.

>  # forces evaluation
>  p x * 3 # => 24

What will it do for:
  p 3 * x

Thanks for sharing.

5.[ANN] lazy.rb 0.9.5 -- transparent futures!

6. mkmf.rb broken in cvs?

7. setup.rb question

8. setup.rb problems and possible fix



Return to ruby

 

Who is online

Users browsing this forum: No registered users and 61 guest