JSC without Dependencies
My interest in WebKit is integrating my game engine with JSC. I'm far enough into the switch over that I've begun looking at compiling it on my own. My goal -- which might be a fools errand -- is to create a win32 VS compile without dependencies. I don't know if this is something that I could give back to the project or if it's at cross purposes with the project. The goal is to make it as easy as possible for VS users (like it is for XCode users): download, hit compile, and go. Any thoughts on this? A couple steps: 1) Use relative paths to remove the need for WEBKITLIBRARIESDIR and WEBKITOUTPUTDIR -- this can be especially problemantic if you pull the nightly builds as their top directory name changes. 2) Remove the need for external libraries, where possible. The dependent libraries are: CFLite (can be done with a switch, based on previous emails) icu*** (might not be possible, google says these are unicode tools) pthreadVC2 (based on previous email should not be needed) 3) Compile all within VS (no makes or external calls) to eliminate any additional dependencies on other tools Also, has anybody started anything like this, or is it so outside the scope it won't be useful to anybody but me? Or is it just something that will be impossible to untangle? After this I thought about possibly contributing some useful convenience functions, like JSValueIsArray, JSValueMakeArray, etc. [>] Brian
On Mon, Aug 17, 2009 at 9:19 AM, Brian Barnes <ggadwa@charter.net> wrote:
My interest in WebKit is integrating my game engine with JSC. I'm far enough into the switch over that I've begun looking at compiling it on my own. My goal -- which might be a fools errand -- is to create a win32 VS compile without dependencies. I don't know if this is something that I could give back to the project or if it's at cross purposes with the project.
I am unable to help you with this goal, but if you don't care which JS engine you use, note that V8 can be downloaded and compiled standalone (see instructions at http://code.google.com/apis/v8/build.html ) and apparently so can SpiderMonkey (instructions at https://developer.mozilla.org/en/SpiderMonkey_Build_Documentation , I'm not sure if this applies to TraceMonkey as I'm not in the loop on that engine). PK
Peter Kasting wrote:
On Mon, Aug 17, 2009 at 9:19 AM, Brian Barnes <ggadwa@charter.net <mailto:ggadwa@charter.net>> wrote:
My interest in WebKit is integrating my game engine with JSC. I'm far enough into the switch over that I've begun looking at compiling it on my own. My goal -- which might be a fools errand -- is to create a win32 VS compile without dependencies. I don't know if this is something that I could give back to the project or if it's at cross purposes with the project.
I am unable to help you with this goal, but if you don't care which JS engine you use, note that V8 can be downloaded and compiled standalone (see instructions at http://code.google.com/apis/v8/build.html ) and apparently so can SpiderMonkey (instructions at https://developer.mozilla.org/en/SpiderMonkey_Build_Documentation , I'm not sure if this applies to TraceMonkey as I'm not in the loop on that engine).
PK I'm actually switching from SpiderMonkey to JSC right now, for a faster and more modern engine and future (maybe) iPhone development, and that took a couple weeks as is -- switching gears again would kill me! :)
[>] Brian
On Mon, Aug 17, 2009 at 10:22 AM, Peter Kasting <pkasting@google.com> wrote:
I am unable to help you with this goal,
I thought this made it clear that I didn't _know_ whether JSC could be built standalone, but I was informed privately that this looks like I'm saying that it definitively can't. For the record, I didn't intend to imply any such thing. PK
Hi Brian, I just took a look to see why CoreFoundation is being used in JavaScriptCore, and frankly am a little puzzled. A quick check of includes of CoreFoundation shows a handful of files: $ grep -r CoreFoundation * | grep -v ".svn" | grep "#include" API/JSStringRefCF.h:#include <CoreFoundation/CoreFoundation.h> runtime/DatePrototype.cpp:#include <CoreFoundation/CoreFoundation.h> wtf/Assertions.cpp:#include <CoreFoundation/CFString.h> wtf/CurrentTime.cpp:#include <CoreFoundation/CFDate.h> wtf/RetainPtr.h:#include <CoreFoundation/CoreFoundation.h> wtf/unicode/icu/CollatorICU.cpp:#include <CoreFoundation/CoreFoundation.h> All of these are actually conditionalized on PLATFORM(MAC), except the API/JSStringRefCF.h. In theory, you could remove the JSStringRefCF from the set of build files and remove the dependency on CoreFoundation/CFLite entirely. It doesn't even look like the JavaScriptCore.def references any of the CFStringRef-related functions. I am actually surprised that the date/time and Collator sources don't use CoreFoundation on Windows. Apple spent a bunch of time writing these compatibility routines that provide superior formatting of dates, handling of low-level time intervals, etc... Why are we not using them? Bottom line Brian, is that you should create a non-PLATFORM(CF) build of JavaScriptCore: 1. Duplicate the Windows vcproj. 2. Remove the JSStringRefCF.cpp/.h files from the list of build items. 3. Remove the CFLite.lib link command. Voila -- you should have a CFLite-less build. On Mon, Aug 17, 2009 at 9:19 AM, Brian Barnes<ggadwa@charter.net> wrote:
icu*** (might not be possible, google says these are unicode tools)
The wtf/unicode things need these libraries. I'm not sure how wise it would be to remove them, however this is the largest single external dependency you will have to deal with.
pthreadVC2 (based on previous email should not be needed)
I'd like to get rid of this, too.
3) Compile all within VS (no makes or external calls) to eliminate any additional dependencies on other tools
You can already do this. You only need cygwin to easily handle retrieving the sources, and I think the Google/Chromium guys have been working to remove this dependency. -Brent
On Aug 17, 2009, at 11:04 AM, Brent Fulgham wrote:
On Mon, Aug 17, 2009 at 9:19 AM, Brian Barnes<ggadwa@charter.net> wrote:
icu*** (might not be possible, google says these are unicode tools)
The wtf/unicode things need these libraries. I'm not sure how wise it would be to remove them, however this is the largest single external dependency you will have to deal with.
It may be possible to replace ICU use with MultiByteToWideChar/ WideCharToMultiByte and similar functions from Win32.
pthreadVC2 (based on previous email should not be needed)
I'd like to get rid of this, too.
May be possible to replace this with native Win32 threading and synchronization calls. I think some work may have been done here already.
3) Compile all within VS (no makes or external calls) to eliminate any additional dependencies on other tools
You can already do this. You only need cygwin to easily handle retrieving the sources, and I think the Google/Chromium guys have been working to remove this dependency.
This one is harder, since JavaScriptCore uses bash, make, perl, and bison (at least) from cygwin. See the JavaScriptCoreGenerated vcproj, build-generated-files.sh, DerivedSources.make. I agree that it would be great to remove this dependency.
-Brent _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Steve Falkenburg wrote:
On Aug 17, 2009, at 11:04 AM, Brent Fulgham wrote:
On Mon, Aug 17, 2009 at 9:19 AM, Brian Barnes<ggadwa@charter.net> wrote:
icu*** (might not be possible, google says these are unicode tools)
The wtf/unicode things need these libraries. I'm not sure how wise it would be to remove them, however this is the largest single external dependency you will have to deal with.
It may be possible to replace ICU use with MultiByteToWideChar/WideCharToMultiByte and similar functions from Win32.
The WINCE implementation might be helpful here. It depends on some data tables taken from ICU which we decided not to check in, but you can still find them in the older patches attached to this bug: https://bugs.webkit.org/show_bug.cgi?id=27305
3) Compile all within VS (no makes or external calls) to eliminate any additional dependencies on other tools
You can already do this. You only need cygwin to easily handle retrieving the sources, and I think the Google/Chromium guys have been working to remove this dependency.
This one is harder, since JavaScriptCore uses bash, make, perl, and bison (at least) from cygwin. See the JavaScriptCoreGenerated vcproj, build-generated-files.sh, DerivedSources.make. I agree that it would be great to remove this dependency.
I don't think this is worth the pain, since it's entirely a build-time dependency and won't affect your generated library at all. Is installing cygwin really that hard? (If it's a matter of bloat, can you replace the cygwin tools with msys? I haven't tried.) Joe
Joe Mason wrote:
Steve Falkenburg wrote:
On Aug 17, 2009, at 11:04 AM, Brent Fulgham wrote:
3) Compile all within VS (no makes or external calls) to eliminate any additional dependencies on other tools
You can already do this. You only need cygwin to easily handle retrieving the sources, and I think the Google/Chromium guys have been working to remove this dependency.
This one is harder, since JavaScriptCore uses bash, make, perl, and bison (at least) from cygwin. See the JavaScriptCoreGenerated vcproj, build-generated-files.sh, DerivedSources.make. I agree that it would be great to remove this dependency.
I don't think this is worth the pain, since it's entirely a build-time dependency and won't affect your generated library at all. Is installing cygwin really that hard? (If it's a matter of bloat, can you replace the cygwin tools with msys? I haven't tried.)
Joe Yes, this is the one that stops the compile, which is why I was going to attempt to rebuild the project from the source files (if possible.) It's no so much "how hard or not hard" it is to install cygwin, it's that most win32 development happens on VS, it's the tool most win32 developer are used to (and a lot of them have seen no other tool), and it makes a bit more sense that the win32 VS compile should just require VS.
Obviously, what I'm doing has little -- read zilch -- impact on the important work of webkit -- so I never expected anything but maybe I could put together a VS project that other could use to build it easier on win32. My project itself is more OS X centric, and I'd like to transfer the ease of use build from one to the other. My case -- if I had to make one -- is that JS engines are getting embedded in lots of different application. It's almost become the language of choice in lots of places -- having a JS engine that can compile easily in systems people are used to is nice. (BTW: Side note: Either I missed this completely or somebody added in class level variables, literally within a week after I asked for it in a different and less effective manner. This is a great time and code saver for me -- so either I'm an idiot for missing it or thanks for the fast work.) [>] Brian
Hi Brian, On Mon, Aug 17, 2009 at 11:54 AM, Brian Barnes<ggadwa@charter.net> wrote:
This one is harder, since JavaScriptCore uses bash, make, perl, and bison (at least) from cygwin. See the JavaScriptCoreGenerated vcproj,
I don't think this is worth the pain, since it's entirely a build-time dependency and won't affect your generated library at all. Is installing cygwin really that hard? (If it's a matter of bloat, can you replace the
Yes, this is the one that stops the compile, which is why I was going to attempt to rebuild the project from the source files (if possible.) It's no so much "how hard or not hard" it is to install cygwin, it's that most win32 development happens on VS, it's the tool most win32 developer are used to (and a lot of them have seen no other tool), and it makes a bit more sense that the win32 VS compile should just require VS.
As a full time Windows developer, I'm afraid I really disagree with you on this topic. I don't think it's correct that since most win32 development happens (only) in VS, that it follows that we should aim to only use Visual Studio. I think this limits us to the same poor environment that leads to so much awful Windows software. For that matter, most Windows developers don't bother building 'utility' libraries like JavaScriptCore themselves; they generally just want to install an SDK and get on with their work. Windows development does occur primarily in VS, but I think this is part of the reason there is so much bad windows code written. WebKit uses tools like Perl to automate generation of various boilerplate interfaces from definitions, and does so in a cross-platform way. Restricting ourselves to VS-only would probably mean having to manually keep all of this stuff in sync (no thank you!) It might be possible to use only ActiveState Perl and Python (and ditch all bash scripting), but I'm not sure how much effort would be involved in doing so. This would still require generating the gperf output used somehow (perhaps that could be maintained as a static text file in the build). Oh -- It would also require the creation of NMAKE-compatible Makefiles to drive the build process (yet another needless replication of a cross-platform tool). While the current set of tools in WebKit is by no means perfect, it is a well designed system for maintaining functionally-equivalent builds of WebKit on all major (and many very tiny!) platforms. I think your efforts would be better served by: 1. Getting your environment set up with Cygwin and building properly. 2. Coming up with patches to reduce the external dependencies (CFLite, ICU, pthreadsv2). 3. Providing pre-build binaries of your dependency-free JavaScriptCore.dll for people to use in their own projects. I fully agree that reduced dependencies are a good idea, but I've come to really like CoreFoundation (CFLite) and don't really care that much about having the other dependencies as long as I can stay up-to-date with WebKit's main development. -Brent
On Aug 17, 2009, at 7:08 PM, Brent Fulgham wrote:
As a full time Windows developer, I'm afraid I really disagree with you on this topic. I don't think it's correct that since most win32 development happens (only) in VS, that it follows that we should aim to only use Visual Studio. I think this limits us to the same poor environment that leads to so much awful Windows software.
Well, the last thing this should turn into is a discussion about development environments :)
For that matter, most Windows developers don't bother building 'utility' libraries like JavaScriptCore themselves; they generally just want to install an SDK and get on with their work.
Windows development does occur primarily in VS, but I think this is part of the reason there is so much bad windows code written. WebKit uses tools like Perl to automate generation of various boilerplate interfaces from definitions, and does so in a cross-platform way. Restricting ourselves to VS-only would probably mean having to manually keep all of this stuff in sync (no thank you!)
It might be possible to use only ActiveState Perl and Python (and ditch all bash scripting), but I'm not sure how much effort would be involved in doing so. This would still require generating the gperf output used somehow (perhaps that could be maintained as a static text file in the build). Oh -- It would also require the creation of NMAKE-compatible Makefiles to drive the build process (yet another needless replication of a cross-platform tool).
While the current set of tools in WebKit is by no means perfect, it is a well designed system for maintaining functionally-equivalent builds of WebKit on all major (and many very tiny!) platforms.
I think your efforts would be better served by: 1. Getting your environment set up with Cygwin and building properly. 2. Coming up with patches to reduce the external dependencies (CFLite, ICU, pthreadsv2). 3. Providing pre-build binaries of your dependency-free JavaScriptCore.dll for people to use in their own projects.
I fully agree that reduced dependencies are a good idea, but I've come to really like CoreFoundation (CFLite) and don't really care that much about having the other dependencies as long as I can stay up-to-date with WebKit's main development.
I'll certainly refrain to you guys and your much greater area of expertise in JSC; I'm sure there's a good reason for everything that goes on. I'll think I'll take this path first, as you suggested, and see how far I can get. Hopefully I'll get done with my main switch over any day now and can begin to get into the JSC code. The fact is, if you are using perl to build files, there's no way around that, so we might be stuck. I'll put up more when I get further. Thanks for all the help and discussion! [>] Brian
Hi Brian, On Mon, Aug 17, 2009 at 6:38 PM, Brian Barnes<ggadwa@charter.net> wrote:
On Aug 17, 2009, at 7:08 PM, Brent Fulgham wrote:
As a full time Windows developer, I'm afraid I really disagree with you on this topic. I don't think it's correct that since most win32 development happens (only) in VS, that it follows that we should aim to only use Visual Studio. I think this limits us to the same poor environment that leads to so much awful Windows software.
Well, the last thing this should turn into is a discussion about development environments :)
Yes -- I'm sorry that my last e-mail came of sounding a bit snarky! It sounded more jocular in my head as I wrote it, but when looking at it later I realized it read in a more preachy fashion than I would have liked. One possible solution to your problem might be to mirror the JavaScriptCore subversion tree, and simply add local files in your repository that are the result of running the make/Perl scripts to generate the various interface files. So the workflow might be to (1) update webkit, (2) run a build to generate the various *.cpp/*.h files, (3) copy JavaScriptCore files to your local subversion repository, (4) verify everything builds in your VS-only project, and publish those sources in a "Windows-only JavaScriptCore" repository for your game. Otherwise, I'm not sure how to accommodate your goals. -Brent
Hi, All, The current webkit database/storage is implemented with creating new threads. But not all platform/products support mulple-threading. Also, threading can be expensive on some platforms. Except this database/storage implementation, WEBKIT platform-crossing code can build and run in a single thread. WEBKIT generally uses WebCore::Timer To avoid blocking UI. Another way to avoid blocking UI is to create a separate thread for UI, and WEBKIT code can still run in a single-thread. Now it's broken by database/storage code, which forces to use multiple threads for WEBKIT. In our WINCE port, we have implemented a single-threaded solution with WebCore::Timer. The patch has been post to https://bugs.webkit.org/show_bug.cgi?id=28019 . The patch is a bit out-of-date, due to changes in upstream. New patch will come soon. Please give some comments if you're interested. There's a macro ENABLE_JSC_MULTIPLE_THREADS used in JSC. Probably there should also be a macro ENABLE_WEBCORE_MULTIPLE_THREADS. Or just use ENABLE_MULTIPLE_THREADS for all multi-threading code. Best regards to everyone, Yong Li
On 18-Aug-09, at 1:44 PM, Yong Li wrote:
Hi, All,
The current webkit database/storage is implemented with creating new threads. But not all platform/products support mulple- threading. Also, threading can be expensive on some platforms. Except this database/storage implementation, WEBKIT platform- crossing code can build and run in a single thread. WEBKIT generally uses WebCore::Timer To avoid blocking UI. Another way to avoid blocking UI is to create a separate thread for UI, and WEBKIT code can still run in a single-thread. Now it's broken by database/ storage code, which forces to use multiple threads for WEBKIT. In our WINCE port, we have implemented a single-threaded solution with WebCore::Timer. The patch has been post to https://bugs.webkit.org/ show_bug.cgi?id=28019 . The patch is a bit out-of-date, due to changes in upstream. New patch will come soon. Please give some comments if you're interested.
There's a macro ENABLE_JSC_MULTIPLE_THREADS used in JSC. Probably there should also be a macro ENABLE_WEBCORE_MULTIPLE_THREADS. Or just use ENABLE_MULTIPLE_THREADS for all multi-threading code.
I agree with that and I think a cleanup of the patch would make it a good addition. Forcing the use of threads here is not ideal. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/
Hi All, QtWebKit has a build time flag called ENABLE_SINGLE_THREADED to turn off ENABLE_JSC_MULTIPLE_THREADS and WebCore features that create additional threads. I'm interested to make this feature available for QtWebKit (and maybe other ports) as well, not just to the WINCE port. See http://trac.webkit.org/changeset/44411. Regards, Laszlo -----Original Message----- From: webkit-dev-bounces@lists.webkit.org [mailto:webkit-dev-bounces@lists.webkit.org] On Behalf Of ext George Staikos Sent: Tuesday, August 18, 2009 10:36 PM To: WebKit Development Subject: Re: [webkit-dev] Single-threaded database/storage solution On 18-Aug-09, at 1:44 PM, Yong Li wrote:
Hi, All,
The current webkit database/storage is implemented with creating new threads. But not all platform/products support mulple- threading. Also, threading can be expensive on some platforms. Except this database/storage implementation, WEBKIT platform- crossing code can build and run in a single thread. WEBKIT generally uses WebCore::Timer To avoid blocking UI. Another way to avoid blocking UI is to create a separate thread for UI, and WEBKIT code can still run in a single-thread. Now it's broken by database/ storage code, which forces to use multiple threads for WEBKIT. In our WINCE port, we have implemented a single-threaded solution with WebCore::Timer. The patch has been post to https://bugs.webkit.org/ show_bug.cgi?id=28019 . The patch is a bit out-of-date, due to changes in upstream. New patch will come soon. Please give some comments if you're interested.
There's a macro ENABLE_JSC_MULTIPLE_THREADS used in JSC. Probably there should also be a macro ENABLE_WEBCORE_MULTIPLE_THREADS. Or just use ENABLE_MULTIPLE_THREADS for all multi-threading code.
I agree with that and I think a cleanup of the patch would make it a good addition. Forcing the use of threads here is not ideal. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi, Laszlo, Do you think our single-threaded storage(database) solution can be helpful to you? If so, I'm going to change the switch from PLATFORM(WINCE) to ENABLE(SINGLE_THREADED) or something like that. -Yong ----- Original Message ----- From: <laszlo.1.gombos@nokia.com> To: <staikos@kde.org>; <webkit-dev@lists.webkit.org> Sent: Tuesday, August 18, 2009 3:57 PM Subject: Re: [webkit-dev] Single-threaded database/storage solution
Hi All,
QtWebKit has a build time flag called ENABLE_SINGLE_THREADED to turn off ENABLE_JSC_MULTIPLE_THREADS and WebCore features that create additional threads. I'm interested to make this feature available for QtWebKit (and maybe other ports) as well, not just to the WINCE port. See http://trac.webkit.org/changeset/44411.
Regards, Laszlo
-----Original Message----- From: webkit-dev-bounces@lists.webkit.org [mailto:webkit-dev-bounces@lists.webkit.org] On Behalf Of ext George Staikos Sent: Tuesday, August 18, 2009 10:36 PM To: WebKit Development Subject: Re: [webkit-dev] Single-threaded database/storage solution
On 18-Aug-09, at 1:44 PM, Yong Li wrote:
Hi, All,
The current webkit database/storage is implemented with creating new threads. But not all platform/products support mulple- threading. Also, threading can be expensive on some platforms. Except this database/storage implementation, WEBKIT platform- crossing code can build and run in a single thread. WEBKIT generally uses WebCore::Timer To avoid blocking UI. Another way to avoid blocking UI is to create a separate thread for UI, and WEBKIT code can still run in a single-thread. Now it's broken by database/ storage code, which forces to use multiple threads for WEBKIT. In our WINCE port, we have implemented a single-threaded solution with WebCore::Timer. The patch has been post to https://bugs.webkit.org/ show_bug.cgi?id=28019 . The patch is a bit out-of-date, due to changes in upstream. New patch will come soon. Please give some comments if you're interested.
There's a macro ENABLE_JSC_MULTIPLE_THREADS used in JSC. Probably there should also be a macro ENABLE_WEBCORE_MULTIPLE_THREADS. Or just use ENABLE_MULTIPLE_THREADS for all multi-threading code.
I agree with that and I think a cleanup of the patch would make it a good addition. Forcing the use of threads here is not ideal.
-- George Staikos Torch Mobile Inc. http://www.torchmobile.com/
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Tue, Aug 18, 2009 at 1:02 PM, Yong Li <yong.li@torchmobile.com> wrote:
Hi, Laszlo,
Do you think our single-threaded storage(database) solution can be helpful to you? If so, I'm going to change the switch from PLATFORM(WINCE) to ENABLE(SINGLE_THREADED) or something like that.
I think this would be good. Btw, is there any intention to set up a WINCE or single threaded QT build bot any time soon? Otherwise I'm concerned that some of us working in storage are going to inadvertently break this stuff and have no idea that it happened. J
It has been broken for many times :) If you guys change it very much or very often, probably it's good to create another StorageAreaSync.cpp in storage\single-threaded as you suggested. -Yong ----- Original Message ----- From: Jeremy Orlow To: Yong Li Cc: laszlo.1.gombos@nokia.com ; staikos@kde.org ; webkit-dev@lists.webkit.org Sent: Tuesday, August 18, 2009 4:39 PM Subject: Re: [webkit-dev] Single-threaded database/storage solution On Tue, Aug 18, 2009 at 1:02 PM, Yong Li <yong.li@torchmobile.com> wrote: Hi, Laszlo, Do you think our single-threaded storage(database) solution can be helpful to you? If so, I'm going to change the switch from PLATFORM(WINCE) to ENABLE(SINGLE_THREADED) or something like that. I think this would be good. Btw, is there any intention to set up a WINCE or single threaded QT build bot any time soon? Otherwise I'm concerned that some of us working in storage are going to inadvertently break this stuff and have no idea that it happened. J
On Tue, Aug 18, 2009 at 1:52 PM, Yong Li <yong.li@torchmobile.com> wrote:
It has been broken for many times :)
If you guys change it very much or very often, probably it's good to create another StorageAreaSync.cpp in storage\single-threaded as you suggested.
I don't understand how splitting things into another file would affect things breaking either way. Also, I don't think you answered my question about plans to set up a bot.
Also, I don't think you answered my question about plans to set up a bot.
Sorry for that. we're still trying to finish upstreaming our WINCE port. However, the progress is very slow. I'm not confident that it could be finished in a month :( ----- Original Message ----- From: Jeremy Orlow To: Yong Li Cc: laszlo.1.gombos@nokia.com ; staikos@kde.org ; webkit-dev@lists.webkit.org Sent: Tuesday, August 18, 2009 5:33 PM Subject: Re: [webkit-dev] Single-threaded database/storage solution On Tue, Aug 18, 2009 at 1:52 PM, Yong Li <yong.li@torchmobile.com> wrote: It has been broken for many times :) If you guys change it very much or very often, probably it's good to create another StorageAreaSync.cpp in storage\single-threaded as you suggested. I don't understand how splitting things into another file would affect things breaking either way. Also, I don't think you answered my question about plans to set up a bot.
We used Active Perl and other tools for building wince port with VS. But it requires extra work for keeping up with upstream changes. So finally we switch to use cygwin totally. I like this way, because webkit is a platform-crossing project, we should avoid unnecessary changes for any specific platform/complier, and share as much as possible. -Yong ----- Original Message ----- From: "Brent Fulgham" <bfulgham@gmail.com> To: "Brian Barnes" <ggadwa@charter.net> Cc: <webkit-dev@lists.webkit.org> Sent: Monday, August 17, 2009 7:08 PM Subject: Re: [webkit-dev] JSC without Dependencies Hi Brian, On Mon, Aug 17, 2009 at 11:54 AM, Brian Barnes<ggadwa@charter.net> wrote:
This one is harder, since JavaScriptCore uses bash, make, perl, and bison (at least) from cygwin. See the JavaScriptCoreGenerated vcproj,
I don't think this is worth the pain, since it's entirely a build-time dependency and won't affect your generated library at all. Is installing cygwin really that hard? (If it's a matter of bloat, can you replace the
Yes, this is the one that stops the compile, which is why I was going to attempt to rebuild the project from the source files (if possible.) It's no so much "how hard or not hard" it is to install cygwin, it's that most win32 development happens on VS, it's the tool most win32 developer are used to (and a lot of them have seen no other tool), and it makes a bit more sense that the win32 VS compile should just require VS.
As a full time Windows developer, I'm afraid I really disagree with you on this topic. I don't think it's correct that since most win32 development happens (only) in VS, that it follows that we should aim to only use Visual Studio. I think this limits us to the same poor environment that leads to so much awful Windows software. For that matter, most Windows developers don't bother building 'utility' libraries like JavaScriptCore themselves; they generally just want to install an SDK and get on with their work. Windows development does occur primarily in VS, but I think this is part of the reason there is so much bad windows code written. WebKit uses tools like Perl to automate generation of various boilerplate interfaces from definitions, and does so in a cross-platform way. Restricting ourselves to VS-only would probably mean having to manually keep all of this stuff in sync (no thank you!) It might be possible to use only ActiveState Perl and Python (and ditch all bash scripting), but I'm not sure how much effort would be involved in doing so. This would still require generating the gperf output used somehow (perhaps that could be maintained as a static text file in the build). Oh -- It would also require the creation of NMAKE-compatible Makefiles to drive the build process (yet another needless replication of a cross-platform tool). While the current set of tools in WebKit is by no means perfect, it is a well designed system for maintaining functionally-equivalent builds of WebKit on all major (and many very tiny!) platforms. I think your efforts would be better served by: 1. Getting your environment set up with Cygwin and building properly. 2. Coming up with patches to reduce the external dependencies (CFLite, ICU, pthreadsv2). 3. Providing pre-build binaries of your dependency-free JavaScriptCore.dll for people to use in their own projects. I fully agree that reduced dependencies are a good idea, but I've come to really like CoreFoundation (CFLite) and don't really care that much about having the other dependencies as long as I can stay up-to-date with WebKit's main development. -Brent _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
participants (9)
-
Brent Fulgham
-
Brian Barnes
-
George Staikos
-
Jeremy Orlow
-
Joe Mason
-
laszlo.1.gombos＠nokia.com
-
Peter Kasting
-
Steve Falkenburg
-
Yong Li