I've a Windows port of JavaScriptCore more or less running on my machine. I'll make the sources available in the next day or two for interested parties. This e-mail describes my approach, problems I've encountered and is meant to start a conversation on what would be the best way to integrate this port with mainline sources.
1. For building I've wrote a Makefile.vc makefile. Building is from command line. I was able to build it with Visual Studio 2003 and VS 2005 Beta 2. Failed to compile with VC6 (too many unsupported constructs). Should also work with the free command-line tools that Microsoft provides (basically the compilers without the IDE). The advantage of makefile vs. project files is that only one makefile should work for many compiler versions. The advantage of project files is that windows developer are much more used to developping in an IDE. 2. Windows doesn't ship with ICU so I had to download pre-built ICU dll. They're quite large. I think the overall goal should be to make the build self-contained so it would be good if those pre-built dll's were also stored in CVS. Another option I was thinking about was statically linking with ICU. The dlls are really big and I'm not sure how much of this code is really used (it looks like jsc only links to toupper/tolower functions, but that might still bring the whole unicode data set). My ultimate goal would be to have this code running on Pocket PC/Smartphone devices where (small) size matters. Also, ICU headers in CVS have stripped windows-related code so I had to use the headers from "official" ICU download. 3. Generating grammar files is possible (using windows port of bison) but not easy for a windows programmer. It would be good if pre-generated files were part of cvs (could be in windows-only directory, so that it doesn't pollute the main code). 4. I hand-generated the *.lut.h files and the pcre chartable.c file although it would be fairly easy to add makefile target to do it automatically. 5. I've chosen #ifdef WIN32 as the switch for windows-specific code 6. Currently it only builds as a static library. Building a DLL is a problem. Unlike on Unix, by default symbols are not exported by a DLL. In order to have a given symbol exported in a DLL, it either has to be added to *.def file or prepended with a special __dllspec(export) syntax. A solution that e.g. curl uses is to define EXPORT macro that is empty for unix and __dllspec(export) for Win. The problem with that is that it pollutes the sources. But I'm not sure if the alternative, i.e. manually creating *.def file, is realistic due to the number of functions that need to be exported (I assume that it's a big number, but I might be wrong). 7. I've discovered 2 bugs that are not win-specific (http://bugzilla.opendarwin.org/show_bug.cgi?id=4546 and http://bugzilla.opendarwin.org/show_bug.cgi?id=4548) 8. I've created JavaScriptCore\os-win32 directory to hold win-specific files. So far it only has the minimal stdint.h implementation. Other than that it's just #ifdef'ing here and there to cover superficial differences. I'll try to submit bugs with patches for those issues although in order to have the the thing built, they all have to go. I welcome comments and ideas, especially on #6, how to make building as a DLL possible. -- kjk _______________________________________________ webkit-dev mailing list [email protected] http://www.opendarwin.org/mailman/listinfo/webkit-dev
