Document build requirements

[michaelklishin]

I am trying to install mustang for Travis CI execjs users, no luck so far. I did install scons as README requires. Can you please document other build dependencies?

gem install output:

vagrant@vserver16:~$ gem install mustang
Building native extensions.  This could take a while...
ERROR:  Error installing mustang:
    ERROR: Failed to build gem native extension.

        /home/vagrant/.rvm/rubies/ruby-1.8.7-p334/bin/ruby extconf.rb
checking for main() in -lv8... yes
checking for main() in -lpthread... yes
checking for string.h... yes
checking for ruby.h... yes
checking for v8.h... yes
checking for v8-debug.h... yes
checking for v8-profiler.h... no
creating Makefile

make
g++ -I. -I. -I/home/vagrant/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/1.8/x86_64-linux -I. -DHAVE_STRING_H -DHAVE_RUBY_H -DHAVE_V8_H -DHAVE_V8_DEBUG_H    -Wall -g -rdynamic -fPIC -fPIC -g -O2  -fPIC    -c v8_boolean.cpp
In file included from v8_boolean.cpp:2:
v8_cast.h:21: error: 'RegExp' was not declared in this scope
v8_cast.h:21: error: template argument 1 is invalid
make: *** [v8_boolean.o] Error 1

Gem files will remain installed in /home/vagrant/.rvm/gems/ruby-1.8.7-p334/gems/mustang-0.2.2 for inspection.
Results logged to /home/vagrant/.rvm/gems/ruby-1.8.7-p334/gems/mustang-0.2.2/ext/v8/gem_make.out

g++ version on that machine is

g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3

[nu7hatch]

Ok, i'll check it out.

[michaelklishin]

By the way, that was with libv8 2.0.3. I am working on packaging 3.0.x to see if that helps.

[nu7hatch]

Yeah it's for sure v8 version's fault. RegExp handler was introduced later.

[michaelklishin]

Well, how about documenting this? So far I have spent a couple of hours figuring out what execjs does, what mustang does, what exactly do they need and how do I get a .deb for that stuff for Ubuntu 10.04.2 that Travis workers use.

This is, you know. A little frustrating. Maybe cool Ruby kids who love cool V8 stuff may also consider writing some doco for us not on the bleeding edge train?

[nu7hatch]

Don't forget that mustang contains bundled, working version of v8. If you're going to use external stuff (especially super old version) then you have to consider possible quirks.

[michaelklishin]

For Travis specifically, this means one of the following scenarios:

• We install mustang into the global gemset. Will be a very tough sell to the rest of the Travis team.
• We ask all the projects that use execjs to add mustang dependency.

Are there any other way to get execjs going via mustang? My idea right now is not so much to use mustang but rather to use mustang to verify that libv8 installation is up-to-date. Then we will probably package node.js 0.4.x and be done with execjs. But if we can use mustang instead of packaging Node, I will be very happy to do so.

[nu7hatch]

Just for curiosity... for what purposes you want to use mustang in Travis? Anyway honestly, mustang's speed is outstanding comparing to therubyracer gem, but still it's only proof of concept, i'm not sure if it's stable enough to use it in production (it lacks some features too, check out issues for details...)

[michaelklishin]

Travis is a community CI service. execjs has moved to travis and they need JS runtimes to be available. We installed it by hand for the current production version but our next release uses automated provisioning with Chef, and I am looking into ways to provide libv8 3.0.x or 3.1.x and probably Node so that execjs itself and its users can have some choice.

So far I came to the conclusion that I have to build libv8 x32 for Ubuntu 10.04.2 myself, then do the same with Node 0.4.x.