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
_______________________________________________
webkit-help mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-help
