The source nightly-builds found at http://nightly.webkit.org/builds/trunk/src/1 have important discrepancies from their respective SVN revisions. Some of these are intentional, such as the exclusion of the tests folders, and are not the subject of this bug. The source nightly-build should maximally reproduce the respective SVN revision and should never alter the exported files, especially in ways that may break the build. Concretely, here are three types of discrepancies that may have serious consequences: 1) Missing folders with all their contents. This includes many android folders as well as gyp, qt and related folders and files. This may be intentional and, unless building affected ports should be supported from source nightly-builds, they may remained excluded from these dumps. 2) Differences in contents. Some files contain vastly different code in them. This either suggests intentionally placing different versions of these files in the source nightly-builds as opposed to the SVN or they come from a different origin or revision than the one advertised by the nightly-build. Files of note in this category are Tools\BuildSlaveSupport\build-launcher-app, Tools\BuildSlaveSupport\build-launcher-dmg, Tools\WebKitLauncher\Configurations\Base.xcconfig and Tools\WebKitLauncher\WebKitLauncherURLProtocol.m to name but a few. 3) Differences in formatting. Some files that otherwise don't differ in content differ in formatting or line-ending. Of these files WebKitLibraries\win\tools\scripts\feature-defines.sh is the most notable, which has CRLF ending in SVN while in the source nightly-builds its line-endings are LF only. Unfortunately, this small difference is breaking the build on some Cygwin systems. For completeness, here is a partial output from a failed build: 4>------ Build started: Project: WebCoreGenerated, Configuration: Release_Cairo_CFLite Win32 ------ 4> 0 [main] which 22080 tty_list::allocate: No tty allocated 4> /usr/bin/bash 4> 0 [main] bash 5760 tty_list::allocate: No tty allocated 4> /cygdrive/c/Cygwin/home/Ash/r107399/WEBKIT~1/win/tools/scripts/feature-defines.sh: line 2: $'\r': command not found 4> /cygdrive/c/Cygwin/home/Ash/r107399/WEBKIT~1/win/tools/scripts/feature-defines.sh: line 24: $'\r': command not found 4> /cygdrive/c/Cygwin/home/Ash/r107399/WEBKIT~1/win/tools/scripts/feature-defines.sh: line 32: syntax error: unexpected end of file Fortunately, the SVN version causes no issues and, it's reasonable to assume, it also works on other platforms/systems. Therefore the remedy is to simply avoid any line-ending conversions while exporting the nightly-builds. The revision used to generate this report was r107399. The source nightly-build can be found at r107399.tar.bz2">http://builds.nightly.webkit.org/files/trunk/src/WebKit-r107399.tar.bz2.
(In reply to comment #0) > Fortunately, the SVN version causes no issues and, it's reasonable to assume, it also works on other platforms/systems. Therefore the remedy is to simply avoid any line-ending conversions while exporting the nightly-builds. > CORRECTION: The SVN version, which contains CRLF is the one broken on said cygwin system. The source nightly-build, which contains LF only, works just fine.
Many, if not most, .sh scripts have svn:eol-style property set to LF. The feature-defines.sh mentioned above has it set to Native, which on Windows is CRLF. It seams reasonable to mark *all* shell scripts (probably all perl and python scripts as well) to LF. This should fix script errors due to line-ending issues. This needs to be approved and someone with commit rights should do the trick as changing properties can't be done by patches, AFAIK.
It seems like the committed version of build-launcher-app is way out of date, as is the WebKitLauncher.xcodeproj and related sources. In no particular order, build-launcher-app doesn't copy Frameworks into the correct directory. WebKitLauncher looks in ./Contents/Frameworks/10.x/, while the build-launcher-app will copy Frameworks into ./Contents/Resources/. Base.xcconfig is way out of date, causing the wrong compiler and SDKROOT path to be used. This can be mostly fixed by copying most of MiniBrowser's Base.xcconfig into WebKitLauncher's version.
(In reply to comment #3) > It seems like the committed version of build-launcher-app is way out of date, as is the WebKitLauncher.xcodeproj and related sources. mostly fixed by copying most of MiniBrowser's Base.xcconfig into WebKitLauncher's version. It seems like the versions included in the Source Nightlies are the versions actually used to produce the binary nightlies. Maybe these should be committed...
I think some of these were fixed recently.