[webkit-help] WebKit "BUILD FAILED"

[Brent Fulgham]

Hi Nicholas,


On Jul 28, 2009, at 10:15 PM, Nicholas Geier wrote:

> Let’s just assume for a moment that I followed the instructions the  
> exact same way as everyone else that is doing this on a Windows  
> Vista system.  The key issue isn't so much the fact I get BUILD  
> FAILED, time after time after time.  The issue is that the results  
> are different each and every time.  I think the reason behind that  
> has to be discovered before I can move forward.


One problem I have had in the past is that the contents of the build  
directory (i.e., the location pointed at by "WEBKITOUTPUTDIR") are not  
reliably cleaned out.  Normally this doesn't matter, but when  
something is screwed up, or when someone has checked in changes that  
affect the autogenerated files (which isn't all that frequent) it can  
cause lots of annoying build failures.  The fix there is to wipe out  
the WEBKITOUTPUTDIR directory tree so you truly start from a clean  
build.

The include paths in your Visual Studio 2005 environment must point at  
the "Windows Server 2003 R2 Platform SDK" location.  If you use the  
"Windows Server 2008" directories (the "Windows SDK/6.1" directory),  
you will get the wrong midl compiler and platform headers.  It's not  
too hard to get that to work, but it adds another difference to your  
setup, which I think is worth avoiding for now.  It will also prevent  
you from accessing the 'mfc' stuff (which doesn't seem to ship in the  
v6.1/2008 SDK), which is needed to get the ImageDiff, TestNSAPI, and  
some of the other utilities to build.

I think we should take a look at what is failing in your build.   
Generally, the order will be as follows (from memory, so hopefully I  
won't transpose any of these, but it should be close):

1.  The WTF library is built.  This should succeed as it relies on  
very little external libraries.
2.  The JavaScriptGenerated library.  Several of these are generated  
by Perl scripts.  I have only run this using the Cygwin Perl; I avoid  
having the ActiveState Perl in my PATH for building WebKit; if you  
accidentally use ActiveState or another Win32-specific build it will  
inject CR/LF endlines into the some of the intermediary files, which  
causes the 'gperf' utility to choke thinking its found a ton of  
duplicate lines.
3.  The JavaScriptCore DLL.  This depends on the first two, so if  
either fail it will fail.
4.  The WebCoreGenerated project.  Again, parts of this are auto- 
generated by Perl, so check your build log.
5.  The WebCore library.  This depends on the WTF, JavaScriptCore, and  
WebCoreGenerated stuff.  If they fail, so will this.  If it SUCCEEDS,  
it will perform some post-build steps that land header files in a  
location where the WebKit project will expect to find them.
6.  The WebKit DLL.  This depends on all the forgoing, as well as the  
post-build step.
7.  ImageDiff utility.  Not important for you.
8.  TestNSAPI utility.  Not important for you.
9.  DumpRenderTree utility.  Not important for you.
10.  WinLauncher.  This application will use the built WebKit, and is  
a great way to test new builds.

Because the scripts sling files around during the build, I'm not  
surprised that you get strange behavior after failures.  It may be  
that some post-build events are firing in some failure cases or so  
on.  My guess is that JavaScriptGenerated is failing for some reason.

I think the best way for us to troubleshoot is for you to e-mail the  
build log (or post it to a paste server) so we can take a look.   
Otherwise, all I can do is keep telling you the same (probably  
annoying) suggestions :-)

-Brent

  
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-help/attachments/20090728/149ba91e/attachment.html>