New build system infra
Hi, If you've been watching the commits, you'll know that in preparation for the switch to Git on Sunday, I have been reworking how the libraries and tools find/use the shared build infrastructure. I have been removing the use of svn:externals since we could not agree on a fully acceptable way to expose them with Git. As such, there is now a Makefile in tools/buildsystem and before you do anything else, you should svn up in that tree and run the makefile. That makefile will install into $PREFIX/share/netsurf-buildsystem all the shared makefiles and test tools. If you really don't want to do that, then you can, instead, export NSSHARED in your environment as the full path to the tools/buildsystem checkout (i.e. the dir containing example, makefiles, testtools, llvm, etc). Then you can svn up in the library trees and they should continue to build as before. Once the Git transition is complete, the externals warts will vanish. A variant of this information will be presented as part of the 'Getting started with building NetSurf from source' wiki page I'll be roughing out before the end of Sunday. D. -- Daniel Silverstone http://www.netsurf-browser.org/ PGP mail accepted and encouraged.Key Id: 3CCE BABE 206C 3B69
Re: JavaScript
Am Freitag, den 29.06.2012, 19:24 +0200 schrieb Chris Young chris.yo...@unsatisfactorysoftware.co.uk: v1.50-2 (which is positively prehistoric, but the only working ported version I have) unfortunately does not work, I fudged it with some macros from newer Spidermonkey includes, and it is calling alert (warn_user()) but with no text. Not sure if it is easy to get it working, for such an old version it's probably not worth it. I have a quick port of Spidermonkey 1.85 but having issues with it crashing; I guess I have quite a while to fix this though. I'd be interested to hear which versions of Spidermonkey are ported to other operating systems we target (and any porting tips!) Hello, my local working copy already works well with spidermonkey-1.7. It's easy. The main problem is: 1. some macros are missing. That's easy, just take the ones from spidermonkey 1.8.5 2. more important - JSFastNative has become JSNative. Old version of JSNative was dropped in 1.8. That's why we need an intermediate macro for JS_FS, JS_FN. ( The newer spidermonkey JSNative prototype is the old JSFastNative!) I'm going to send patches this night. It will make alert() work. I've already send an patch for another problem which also applies to newer spidermonkey versions. (Altough the newer spidermonkey may detects the error and does nothing in the wrong destruction order.) If people do not want spidermonkey 1.7 support, please let me know before I put more work in it. Greets, Ole
Re: JavaScript
On Fri, Jun 29, 2012 at 06:24:58PM +0100, Chris Young wrote: On Fri, 29 Jun 2012 17:28:39 +0100, Vincent Sanders wrote: A simple javascript abstraction has been added allowing for alternative javascript interpreters to be added in future. And an initial implementation added for the spidermonkey interpreter/jit (jsapi) this integration allows for javascript code to be correctly gathered and executed from script tags. That's good to hear. Spidermonkey is perhaps a bit heavy, partly due to being C++ (so the std C++ lib has to be loaded too), and the spidermonkey versions i have been targetting are the c API versions of the 1.8 series so are simply heavy rather than obease current versions are awkward to port due to the dependency on NSPR (although there is a Bugzilla open to remove this dependency which I'm keeping my eye on). Unfortunately it's probably our best option - I don't know of any decent lighter Javascript engines. I tried v8 and looked at a couple of others but none are vaugely usable in our situation and really few of the larger js libs are usuable outside their parent browser projects. What is now required is to add bindings to the javascript runtime for all the DOM operations including the so called DOM0 objects like the global window object and all the associated sub objects like navigator, console etc. Would that need to be done again if somebody decides to add support for a different Javascript library? alas, yes, which is why I tried to work from the web IDL, turns out the IDL samples are incomplete and kinda assume a type system that does not exist within javascript and fits very badly, at which point working from them is pointless as you end up with special casing to make the ideal spec fit the real world. Oh and add in the IDL is simply missing for most of DOM0 Although there is no explicit dependency on specific versions of spidermonkey I am primarily basing my efforts on the 1.8.5 releases as this are the most common version found in distributions. v1.50-2 (which is positively prehistoric, but the only working ported version I have) unfortunately does not work, I fudged it with some macros from newer Spidermonkey includes, and it is calling alert (warn_user()) but with no text. Not sure if it is easy to get it working, for such an old version it's probably not worth it. I have a quick port of Spidermonkey 1.85 but having issues with it crashing; I guess I have quite a while to fix this though. most probably because the JSAPI native calling function spec changed in an incompatible way! can you tell me what JS_VERSION is on your version of the library? I might be able to come up with something...but currently I am a bit stumped how to alter the native calling convention at compile time without some hedious macro magic I'd be interested to hear which versions of Spidermonkey are ported to other operating systems we target (and any porting tips!) Chris - Debian squeeze has 1.8.0 - Debian wheezy has 1.8.5 - I have dev builds using 1.8.9 but they are not really representative of anything - Ubuntu 11.04 has 1.8.5 in the alternate include layout (thats why there are two pkgconfig names/paths sigh) - Ubuntu 11.10 and later seems to be 1.8.5 in various include layouts So I guess that answers the question about which API major version to pick, I think 1.8 series is still the right target -- Regards Vincent http://www.kyllikki.org/
Re: JavaScript
Am Freitag, den 29.06.2012, 19:24 +0200 schrieb Chris Young chris.yo...@unsatisfactorysoftware.co.uk: v1.50-2 (which is positively prehistoric, but the only working ported version I have) unfortunately does not work, I fudged it with some macros from newer Spidermonkey includes, and it is calling alert (warn_user()) but with no text. Not sure if it is easy to get it working, for such an old version it's probably not worth it. I have a quick port of Spidermonkey 1.85 but having issues with it crashing; I guess I have quite a while to fix this though. This patch adds support for older spidermonkey versions (tested with 1.7): http://pastebin.com/XEUhYhYY You still have to pass the following defines to the compiler to make it work: -DXP_UNIX /* Really? Shouldn't it be defined by some jsapi include? */ -DPOSIX_SOURCE -D_BSD_SOURCE /* depends on your build of spidermonkey. */ -DJS_HAS_FILE_OBJECT=0 -DJS_VERSION=170 -DJSVERSION_LATEST=170 -DJSOPTION_JIT=0 Also remember to update desktop/netsurf.c Greets, Ole
