Hi Mike, did you mean to include all of src/v8-read-only in a recent update?
One way to get SilkJS well distributed is simply to have it packaged by upstream distro maintainers and that's best done by having a versioned tarball available and an easy way to do that is using tagged downloads at github. If debian/ubuntu and fedora distro packagers package up SIlkJS then that covers 90% of linux distribution needs right there. No need to do it yourself if you make it easy for "them" to do it.
However, because you've added 90Mb of v8 inside the SIlkJS repo it's not reasonable to use the Github auto zip/tarball tagging method so the only way to provide a tarball usable by upstream distros is to create one yourself without the v8 directory (no one wants to download a ~90Mb tarball to build a 1Mb executable).
I also can't really use an Archlinux PKGBUILD for the same reason, either a straight forward git clone or via the tagged auto tarball system. As an example I just tagged my midicomp repo and built the binary x64 package and this is how it looks. First the PKGBUILD script (a bit like a rpm spec file)...
and note the source=() line. That pulls a tarball that is auto generated by Github from...
and in my case, and hopefully for SilkJS RSN, the binary package ends up here...
note the midicomp package, and also the mm package which is needed for a SilkJS package because the standard Archlinux packages include all the SilkJS needs except for this rather old mm package.
Here's a page about tagging...
Yes, that's a problem with v8, debian stable only has a libv8-2.2.4 but at least ubuntu 11.10 has a libv8-184.108.40.206 which might be recent enough. My archlinux testing repo has v8 220.127.116.11 built on the 9th Oct.
An option to also build a current libv8 package is definitely needed as well but this issue is what upstream packagers need to concern themselves with. It's kind of up to them to lobby their libv8 packaging compatriots to update the libv8 packages, in an ideal world. Part of the reason for old libv8 packages is that not a lot of other packages depend on it so no one cares.
CMake helps with portability. There is a good, or better, chance that SilkJS would build on OSX and mingw via cmake, given that the other so/dll dependencies were already installed.
So would you be willing to try a libv8 git submodule and a tagged version of SilkJS?
If so, what version should it be and I've been meaning to ask what license is SilkJS to be distributed under (a license is essential for Debian and Archlinux packaging, maybe rpm distros too)?
Looks like Netbeans will work with CMake -> http://forums.netbeans.org/ntopic26390.html
CMake only produces a Makefile anyway, or a windows project file on windows, or nmake on OSX I think.