Hi Brian, On Mon, Aug 17, 2009 at 11:54 AM, Brian Barnes<gga...@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
