Is src/v8-read-only/ needed?

[markc]

Hi Mike, did you mean to include all of src/v8-read-only in a recent update?

[mschwartz]

yeah

Now you just git clone, cd SilkJS, and make

It works :)

On Dec 24, 2011, at 5:57 PM, Mark Constable wrote:

Hi Mike, did you mean to include all of src/v8-read-only in a recent update?

---

Reply to this email directly or view it on GitHub:
#8

[markc]

Certainly makes it a bit easier.

But, and trust me to suggest one, it's 90Mb of extra stuff that some
of us don't need :)

There is an official v8 Git mirror on Github and it's uptodate going
by this git commit that matches the latest svn revision...

http://code.google.com/p/v8/source/detail?r=10301
v8/v8@c91aeb4c

So it would be possible to use the Github v8 repo as a git submodule
to store a virtual link instead of the actual svn contents. A bit
like using svn:externals, however, the downside is that a submodule
stores a particular snapshot and does not automatically track master
like svn:externals do. OTOH svn:externals can't point to a particular
revision other than trunk (I don't think)...

http://help.github.com/submodules/

[mschwartz]

My objective is to make it a snap for people to install and build SilkJS. I'm not finished yet, but at this point it is way easier.

What I am thinking is adding a shell script that people can do something like:
wget http://github.com/mschwartz/SilkJS/install-osx.sh -O - | sudo ti
and it's installed. There's nothing stopping me from having the shell script install the prerequisite libraries, download SilkJS via git, and v8 via subversion, and do the build.

I also made a new make target, bootstrap. This builds a minimal SilkJS without any dependent libraries. I was thinking that with fs and net, the entire build process can be done with JavaScript code, and maybe the binary bootstrap version could be downloadable.

On my list is to make .deb and .rpm files as well.

On Dec 25, 2011, at 4:56 AM, Mark Constable wrote:

Certainly makes it a bit easier.

But, and trust me to suggest one, it's 90Mb of extra stuff that some
of us don't need :)

There is an official v8 Git mirror on Github and it's uptodate going
by this git commit that matches the latest svn revision...

http://code.google.com/p/v8/source/detail?r=10301
v8/v8@c91aeb4c

So it would be possible to use the Github v8 repo as a git submodule
to store a virtual link instead of the actual svn contents. A bit
like using svn:externals, however, the downside is that a submodule
stores a particular snapshot and does not automatically track master
like svn:externals do. OTOH svn:externals can't point to a particular
revision other than trunk (I don't think)...

http://help.github.com/submodules/

---

Reply to this email directly or view it on GitHub:
#8 (comment)

[markc]

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)...

https://raw.github.com/eth-os/srcpkg/master/midicomp/PKGBUILD

and note the source=() line. That pulls a tarball that is auto generated by Github from...

https://github.com/markc/midicomp/tags

and in my case, and hopefully for SilkJS RSN, the binary package ends up here...

http://pkg.eth-os.org/eth-os/x86_64/

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...

http://learn.github.com/p/tagging.html

[mschwartz]

One thing about packages from upstream maintainers is they can rely on something like libv8 that is some really old version compared to what SilkJS currently uses.

What do we do about that?

I am all in favor of improving things.

If you want to rearrange a fork of the repo, I can pull the changes.

On Dec 25, 2011, at 11:14 AM, Mark Constable wrote:

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)...

https://raw.github.com/eth-os/srcpkg/master/midicomp/PKGBUILD

and note the source=() line. That pulls a tarball that is auto generated by Github from...

https://github.com/markc/midicomp/tags

and in my case, and hopefully for SilkJS RSN, the binary package ends up here...

http://pkg.eth-os.org/eth-os/x86_64/

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...

http://learn.github.com/p/tagging.html

---

Reply to this email directly or view it on GitHub:
#8 (comment)

[mschwartz]

I forgot to add, gnu make is mandatory for me. I use Netbeans to develop and it relies on gnu make. Having cmake as an option is fine, though.

On Dec 25, 2011, at 11:14 AM, Mark Constable wrote:

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)...

https://raw.github.com/eth-os/srcpkg/master/midicomp/PKGBUILD

and note the source=() line. That pulls a tarball that is auto generated by Github from...

https://github.com/markc/midicomp/tags

and in my case, and hopefully for SilkJS RSN, the binary package ends up here...

http://pkg.eth-os.org/eth-os/x86_64/

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...

http://learn.github.com/p/tagging.html

---

Reply to this email directly or view it on GitHub:
#8 (comment)

[markc]

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-3.1.8.22 which might be recent enough. My archlinux testing repo has v8 3.6.5.1 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)?

[markc]

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.

[mschwartz]

I forgot to add the license file.

It's MIT, BSD, or WTF, take your pick.
:)

On Dec 25, 2011, at 11:14 AM, Mark Constable wrote:

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)...

https://raw.github.com/eth-os/srcpkg/master/midicomp/PKGBUILD

and note the source=() line. That pulls a tarball that is auto generated by Github from...

https://github.com/markc/midicomp/tags

and in my case, and hopefully for SilkJS RSN, the binary package ends up here...

http://pkg.eth-os.org/eth-os/x86_64/

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...

http://learn.github.com/p/tagging.html

---

Reply to this email directly or view it on GitHub:
#8 (comment)

[markc]

It's MIT, BSD, or WTF, take your pick.

How about making a totally eclectic license statement and adding GPL,
GPLv3 and AGPLv3 options as well?

And the initial release version number?

v0.1.0 is a reasonable starting point.