Merge WebKit at r73109: Initial merge by git.

Change-Id: I61f1a66d9642e3d8405d3ac6ccab2a53421c75d8

1 files changed, 144 insertions, 0 deletions

diff --git a/WebKitLibraries/ChangeLog b/WebKitLibraries/ChangeLog
index bfd54bc..60cb1f6 100644
--- a/WebKitLibraries/ChangeLog
+++ b/WebKitLibraries/ChangeLog
@@ -1,3 +1,147 @@
+2010-12-01  Adam Roben  <aroben@apple.com>
+
+        Don't let harmless errorlevels from the "set" utility leak into
+        project-specific build scripts
+
+        When using set to unset an environment variable that didn't previously
+        exist, set raises the errorlevel to 1. This was leaking into
+        project-specific scripts, causing them to think the build has failed.
+        We now clear the errorlevel after we finish setting environment
+        variables.
+
+        Fixes <http://webkit.org/b/50350> Windows builds mysteriously fail in
+        some configurations
+
+        Reviewed by Steve Falkenburg.
+
+        * win/tools/vsprops/common.vsprops: Call "cmd /c" after setting
+        environment variables to get rid of any errorlevel that "set" set.
+
+2010-12-01  Steve Falkenburg  <sfalken@apple.com>
+
+        Reviewed by Adam Roben.
+
+        vcproj changes can't be applied cleanly by the Windows EWS bot
+        https://bugs.webkit.org/show_bug.cgi?id=50328
+
+        * win/tools/vsprops/WinCairo.vsprops: Added property svn:eol-style.
+        * win/tools/vsprops/cURL.vsprops: Added property svn:eol-style.
+        * win/tools/vsprops/debug_wincairo.vsprops: Added property svn:eol-style.
+
+2010-11-29  Steve Falkenburg  <sfalken@apple.com>
+
+        Windows build fix (part 2).
+        Define Visual Studio internal variables used in pre-build/pre-link/post-build commands in environment for separated cmd files.
+
+        * win/tools/vsprops/common.vsprops:
+
+2010-11-19  Steve Falkenburg  <sfalken@apple.com>
+
+        Reviewed by Adam Roben.
+
+        Add a mechanism for Windows pre-build/pre-link/post-build events to be separated into individual cmd files
+        https://bugs.webkit.org/show_bug.cgi?id=49858
+        
+        We're migrating our prebuild/prelink/postbuild steps out of vcproj and vsprops files:
+        - To simplify editing (editing vsprops build steps is confusing).
+        - For more readable diffs.
+        
+        To add a prebuild/prelink/postbuild step for a vcproj,
+        Add a new file named {ProjectName}PreBuild|PreLink|PostBuild.cmd to the project directory.
+        For example, a WTF prebuild script would be named WTFPreBuild.cmd and would be located
+        in the directory JavaScriptCore/JavaScriptCore.vcproj/WTF (alongside WTF.vcproj).
+
+        * win/tools/vsprops/common.vsprops:
+        * win/tools/vsprops/release.vsprops:
+
+2010-11-29  Anders Carlsson  <andersca@apple.com>
+
+        Reviewed by Sam Weinig and Simon Fraser.
+
+        WebKitSystemInterface.h piece of r72438.
+
+        * WebKitSystemInterface.h:
+
+2010-11-22  Adam Roben  <aroben@apple.com>
+
+        Use paths relative to $WebKitVSPropsRedirectionDir to access shared .vsprops files
+
+        Apple's Windows build allows placing header files and import libraries for WebKit's
+        dependencies (CoreGraphics, CFNetwork, SQLite, etc.) outside the source tree via the
+        $WebKitLibrariesDir environment variable. This is both required for production builds and
+        convenient for Apple-internal developer builds. Apple's production builds also require that
+        WebKit's shared .vsprops files be accessed relative to $WebKitLibrariesDir. In production
+        builds, the files are copied into that directory tree by the
+        WebKitLibraries/win/tools/WinTools.make file. In Apple-internal developer builds, the
+        copying is done by
+        JavaScriptCore/JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.make.
+
+        This .vsprops copying is problematic in one very important case: when a developer updates
+        their source tree and then tries to build. Visual Studio only reads .vsprops files when a
+        project is first loaded. So, when Visual Studio is first opened after the .vsprops files are
+        updated, it reads in the old files that were already residing in $WebKitLibrariesDir. When a
+        build is started, JavaScriptCoreGenerated.make copies the new .vsprops files into
+        $WebKitLibrariesDir, but Visual Studio will not pick up the changes.  The rest of the build
+        will proceed with out-of-date .vsprops files, which will likely result in a build failure.
+
+        To fix this, we now use normal relative paths to access the .vsprops files in the source
+        tree rather than in $WebKitLibrariesDir, but prefix those paths with a new environment
+        variable, $WebKitVSPropsRedirectionDir. In developer builds, this environment variable is
+        unset, so the normal relative paths are used to read the .vsprops files out of the source
+        tree directly. In production builds, this environment variable is set to a fake directory
+        that will cause the .vsprops files in $WebKitLibrariesDir to be found when the relative path
+        is resolved.
+        
+        For example, JavaScriptCore.vcproj uses this path for FeatureDefines.vsprops:
+
+        $(WebKitVSPropsRedirectionDir)..\..\..\WebKitLibraries\win\tools\vsprops\FeatureDefines.vsprops
+
+        In developer builds, where $WebKitVSPropsRedirectionDir is unset, this will point to the
+        files in WebKitLibraries\win\tools\vsprops in the source tree. In production builds,
+        JavaScriptCore.make sets $WebKitVSPropsRedirectionDir to
+        "$(SRCROOT)\AppleInternal\tools\vsprops\OpenSource\1\2\3\", so the full path for
+        FeatureDefines.vsprops becomes:
+
+        $(SRCROOT)\AppleInternal\tools\vsprops\OpenSource\1\2\3\..\..\..\WebKitLibraries\win\tools\vsprops\FeatureDefines.vsprops
+
+        which resolves to:
+
+        $(SRCROOT)\AppleInternal\tools\vsprops\OpenSource\WebKitLibraries\win\tools\vsprops\FeatureDefines.vsprops
+
+        (We rely on the fact that Windows doesn't care whether the directories "1", "2", and "3"
+        actually exist since they are matched by an equal number of ".." path components.)
+
+        Note that Visual Studio still won't pick up changes made to .vsprops files while Visual
+        Studio is open, but that problem hasn't seemed to cause developers many headaches so far.
+
+        Fixes <http://webkit.org/b/49181> Windows build fails mysteriously when .vsprops files are
+        updated
+
+        Reviewed by Dave Hyatt.
+
+        * win/tools/WinTools.make: Copy the shared .vsprops files into a directory tree beneath
+        AppleInternal\tools\vsprops that matches the source directory tree. This allows production
+        builds to redirect the relative paths used to find the shared .vsprops files into
+        AppleInternal by setting $WebKitVSPropsRedirectionDir to the appropriate value.
+
+2010-11-18  Steve Falkenburg  <sfalken@apple.com>
+
+        Rubber-stamped by Adam Roben.
+
+        Remove unused debug_internal vsprops file.
+
+        * win/tools/vsprops/debug_internal.vsprops: Removed.
+
+2010-11-18  Steve Falkenburg  <sfalken@apple.com>
+
+        Reviewed by Adam Roben.
+
+        Debug_Internal Windows configuration is unnecessary, should be removed
+        https://bugs.webkit.org/show_bug.cgi?id=49753
+
+        * win/tools/vsprops/debug.vsprops:
+        * win/tools/vsprops/debug_internal.vsprops:
+
 2010-11-17  Steve Falkenburg  <sfalken@apple.com>
 
         Rubber-stamped by Adam Roben.