Using JavaScriptCore in Win32
I'm attempting to use JSC in my win32 port of my application, and am running into a number of problems. I suspect they all stem from the fact that there must be some #defines I need to properly set before compiling the headers or some other required library or header. This seems to be the case as the first error I get is: #if !PLATFORM(WIN_OS) throws up an "unexpected token". I can obviously work around this one but I suspect there are more. Can anybody give me a list and this should probably be something that's in the docs somewhere. I'm using Express 2008 for the compile. [>] Brian
On Aug 10, 2009, at 8:27 AM, Brian Barnes wrote:
I'm attempting to use JSC in my win32 port of my application, and am running into a number of problems. I suspect they all stem from the fact that there must be some #defines I need to properly set before compiling the headers or some other required library or header. This seems to be the case as the first error I get is:
#if !PLATFORM(WIN_OS)
throws up an "unexpected token".
What header? The code you show above would only be in internal JavaScriptCore headers. These are intended to be used only inside JavaScriptCore itself, or inside other parts of the WebKit project. Public JavaScriptCore headers, like JSObjectRef.h, won't have code like that in them. -- Darin
Darin Adler wrote:
On Aug 10, 2009, at 8:27 AM, Brian Barnes wrote:
I'm attempting to use JSC in my win32 port of my application, and am running into a number of problems. I suspect they all stem from the fact that there must be some #defines I need to properly set before compiling the headers or some other required library or header. This seems to be the case as the first error I get is:
#if !PLATFORM(WIN_OS)
throws up an "unexpected token".
What header? The code you show above would only be in internal JavaScriptCore headers. These are intended to be used only inside JavaScriptCore itself, or inside other parts of the WebKit project.
Public JavaScriptCore headers, like JSObjectRef.h, won't have code like that in them.
-- Darin Hi Darren,
Yes, that's my confusion. I included this header: JavaScriptCore.h Or I included just the headers I needed separately (JSObjectRef, JSValueRef, etc), with the same problem. JSBase.h includes stdbool.h, which is where this error comes from. I need JSBase to compile scripts, unless I'm mistaken here. [>] Brian
On Aug 10, 2009, at 10:44 AM, Brian Barnes wrote:
JSBase.h includes stdbool.h, which is where this error comes from. I need JSBase to compile scripts, unless I'm mistaken here.
The the os-win32 directory is not intended for use from clients using JavaScriptCore, and it shouldn't be in your include path. It’s only for use building JavaScriptCore and WebKit itself on old versions of Windows. I believe if you leave it out of the path, then you will get stdbool.h and stdint.h from Visual Studio itself and everything will be fine. -- Darin
Darin Adler wrote:
On Aug 10, 2009, at 10:44 AM, Brian Barnes wrote:
JSBase.h includes stdbool.h, which is where this error comes from. I need JSBase to compile scripts, unless I'm mistaken here.
The the os-win32 directory is not intended for use from clients using JavaScriptCore, and it shouldn't be in your include path. It’s only for use building JavaScriptCore and WebKit itself on old versions of Windows.
I believe if you leave it out of the path, then you will get stdbool.h and stdint.h from Visual Studio itself and everything will be fine.
-- Darin
There is no such file (stdbool or stdint) for MSVC 9, hence my current problems :) I don't think they've ever had it. I copied over yours to attempt the compile. Note that it would be rather dangerous to use a DLL compiled with different bool's then what I was having in the headers, which is also my desire to get the proper compile for the headers. As a matter of fact, I actually changed my original header typedef of bool to match yours (it doesn't effect my code and will keep it from crashing.) bool still needs to be defined (as far as I can tell) in MSVC 9. [>] Brian
Hi Brian, On Mon, Aug 10, 2009 at 11:01 AM, Brian Barnes<ggadwa@charter.net> wrote:
Darin Adler wrote:
I believe if you leave it out of the path, then you will get stdbool.h and stdint.h from Visual Studio itself and everything will be fine.
There is no such file (stdbool or stdint) for MSVC 9, hence my current problems :) I don't think they've ever had it. I copied over yours to attempt the compile. Note that it would be rather dangerous to use a DLL compiled with different bool's then what I was having in the headers, which is also my desire to get the proper compile for the headers.
I put together an example Windows port of the Apple Developer CallJS example (http://idisk.mac.com/bfulgham-Public/CallJS.zip). In it, I put together a "WebKit SDK" folder with headers, link libraries, and dlls for everything. The Apple port (which you cannot redistribute to end users) requires (among other things) Apple's CoreFoundation library. The CoreFoundation build dependencies include stdbool and stdint header files. The WinCairo port uses the freely redistributable CFLite library, which includes effectively the same stdbool/stdint headers. Thanks, -Brent
Brent Fulgham wrote:
Hi Brian,
On Mon, Aug 10, 2009 at 11:01 AM, Brian Barnes<ggadwa@charter.net> wrote:
Darin Adler wrote:
I believe if you leave it out of the path, then you will get stdbool.h and stdint.h from Visual Studio itself and everything will be fine.
There is no such file (stdbool or stdint) for MSVC 9, hence my current problems :) I don't think they've ever had it. I copied over yours to attempt the compile. Note that it would be rather dangerous to use a DLL compiled with different bool's then what I was having in the headers, which is also my desire to get the proper compile for the headers.
I put together an example Windows port of the Apple Developer CallJS example (http://idisk.mac.com/bfulgham-Public/CallJS.zip). In it, I put together a "WebKit SDK" folder with headers, link libraries, and dlls for everything.
The Apple port (which you cannot redistribute to end users) requires (among other things) Apple's CoreFoundation library. The CoreFoundation build dependencies include stdbool and stdint header files. The WinCairo port uses the freely redistributable CFLite library, which includes effectively the same stdbool/stdint headers.
Thanks,
-Brent OK, but what I want is JavaScriptCore only, to integrate with my game engine (which right now uses SpiderMonkey, the one in FireFox.) I'm hoping that I can get this code alone with the minimal of dependencies, but it seems it hasn't fully been untangled in places.
It has no interface, it should require very little (or no) additional libraries. BTW, this isn't a rant at all -- I'm happy with getting anything and thank you for all the work you guys have done -- I just know this isn't a focus so it's not something that was probably worked out, which is why I'm trying to help. I'm going to try to hack my way into whatever the minimal dependencies for JSC and only JSC, and see what I can come up with, and places where maybe the code could be altered to make it more independent. I *suspect* my biggest trouble is going to come from the CFString that are in there. It would be nice to have a #define where I could ignore those on other platforms (and just use the C strings.) Again, you folks have done a wonderful job with this, I'm not complaining, just trying to help, it's such a new and clean code base, that's one of the reasons I moved to it. [>] Brian
Hi Brian, On Mon, Aug 10, 2009 at 1:14 PM, Brian Barnes<ggadwa@charter.net> wrote:
The Apple port (which you cannot redistribute to end users) requires (among other things) Apple's CoreFoundation library. The CoreFoundation build dependencies include stdbool and stdint header files. The WinCairo port uses the freely redistributable CFLite library, which includes effectively the same stdbool/stdint headers.
OK, but what I want is JavaScriptCore only, to integrate with my game engine (which right now uses SpiderMonkey, the one in FireFox.) I'm hoping that I can get this code alone with the minimal of dependencies, but it seems it hasn't fully been untangled in places.
It has no interface, it should require very little (or no) additional libraries.
Dependency walker tells me that the JavaScriptCore.dll depends on CFLite.dll, pthreadvc2.dl, and ICUUC40.dll. Perhaps these links are not all needed; now that JavaScriptCore is its own DLL, we should be able to get rid of pthreadvc2 (IIRC, the only reason it was kept after the win32 threading work was that a dll target was needed for handling thread shut-down.) I'm not sure if CFLite/CoreFoundation is really needed. Their inclusion in the header file is no doubt the cause of your compiler problems, but it might just be that the CoreFoundation link library was left in when JavaScriptCore was made a separate DLL. Darin, do you know if CoreFoundation is really needed by JavaScriptCore? Or maybe Olliver would know? Thanks, -Brent
Dependency walker tells me that the JavaScriptCore.dll depends on CFLite.dll, pthreadvc2.dl, and ICUUC40.dll. Perhaps these links are not all needed; now that JavaScriptCore is its own DLL, we should be able to get rid of pthreadvc2 (IIRC, the only reason it was kept after the win32 threading work was that a dll target was needed for handling thread shut-down.)
I'm not sure if CFLite/CoreFoundation is really needed. Their inclusion in the header file is no doubt the cause of your compiler problems, but it might just be that the CoreFoundation link library was left in when JavaScriptCore was made a separate DLL.
Darin, do you know if CoreFoundation is really needed by JavaScriptCore? Or maybe Olliver would know?
Beyond the requirements of JSStringRef.h (eg. that a few types exist) there should not be any deliberate dependency on CF in JSC for anything other than platform specific behaviour, and a quick scan indicates that all such sites seem to have appropriate ifdef guards. On non-CF platforms you also only want to include JavaScriptCore/ JavaScript.h not JavaScriptCore/JavaScriptCore.h as it is JavaScriptCore.h that brings in the CF APIs. The only real concern beyond that is to make sure that in builds where you do not want a CF dependency in JSC to ensure that PLATFORM(CF) is false and that JSStringRefCF.cpp is not compiled. In an ideal world that should Just Work. --Oliver
Thanks,
-Brent _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Oliver Hunt wrote:
Dependency walker tells me that the JavaScriptCore.dll depends on CFLite.dll, pthreadvc2.dl, and ICUUC40.dll. Perhaps these links are not all needed; now that JavaScriptCore is its own DLL, we should be able to get rid of pthreadvc2 (IIRC, the only reason it was kept after the win32 threading work was that a dll target was needed for handling thread shut-down.)
I'm not sure if CFLite/CoreFoundation is really needed. Their inclusion in the header file is no doubt the cause of your compiler problems, but it might just be that the CoreFoundation link library was left in when JavaScriptCore was made a separate DLL.
Darin, do you know if CoreFoundation is really needed by JavaScriptCore? Or maybe Olliver would know?
Beyond the requirements of JSStringRef.h (eg. that a few types exist) there should not be any deliberate dependency on CF in JSC for anything other than platform specific behaviour, and a quick scan indicates that all such sites seem to have appropriate ifdef guards.
On non-CF platforms you also only want to include JavaScriptCore/JavaScript.h not JavaScriptCore/JavaScriptCore.h as it is JavaScriptCore.h that brings in the CF APIs. The only real concern beyond that is to make sure that in builds where you do not want a CF dependency in JSC to ensure that PLATFORM(CF) is false and that JSStringRefCF.cpp is not compiled.
In an ideal world that should Just Work.
--Oliver Here's what works so far, and a couple suggestions. Note that I am shifting my engine from SpiderMonkey to JSC, so all I'm concerned with right now is the headers compiling, I have a lot of work ahead to remake the glue code before I attempt to run it with an actuall DLL/LIB combo.
You need these headers: JavaScript.h JSBase.h JSContextRef.h JSObjectRef.h JSStringRef.h JSValueRef.h stdbool.h WebKitAvailability.h And put this in your headers: // get rid of it trying to use STDBOOL #define STDBOOL_WIN32_H // if not already defined by some other code typedef unsigned char bool; #define true 1 #define false 0 #include <JavaScriptCore/JavaScript.h> OK, obviously needing stdbool is a problem here as it's meant for compiling the DLL, not integrating the DLL. Maybe check for windows in JavaScript.h and put the three defines in there? I suspect (could be wrong, didn't check) that JavaScript.h is a header not used in the DLL compile. Then you could remove stdbool from JSBase (where it's referenced.) Obviously, you guy know this code far better than I would :) Another slight problem is that I already defined bool and I suspect a lot of others will when doing cross platform code, so they are going to have to be sure to use the same bool or they'll get a re-def error. Another thing that's a little obnoxious is that you have to have all you .h files in a JavaScriptCore directory because of the OS X naming for the headers. This is not a big deal at all, but could potentially throw off some non OS X users. Not something I'd worry about changing, but maybe something noted in a doc somewhere. This is a really good bit of code for a script engine. The future is javascript embedded in about everything, so the easier it is to compile this alone the better :) [>] Brian
participants (4)
-
Brent Fulgham
-
Brian Barnes
-
Darin Adler
-
Oliver Hunt