Apple Opens WebKit

[Flying Llama]

Hmm, can't seem to get run-webkit-tests to complete successfully. I copied the script, with a few others, to /usr/bin. When I type in run-webkit-tests, I receive the following:

 deprecated option: -buildstyle is no longer supported in xcodebuild. Use -configuration instead.
(NOTE: project DumpRenderTree was written by an older version of Xcode (39) -- temporarily upgrading it to version 42 (without modifying project file))

warning: skipping file '/System/Library/Frameworks/Foundation.framework' (unexpected file type 'folder' in Frameworks & Libraries build phase)
=== BUILDING NATIVE TARGET DumpRenderTree WITH CONFIGURATION Deployment ===

Ld "/Users/alex/Documents/Built Projects/Deployment/DumpRenderTree" normal ppc
    mkdir "/Users/alex/Documents/Built Projects/Deployment"
    cd /Users/alex/WebKitTools/DumpRenderTree
    /usr/bin/gcc-4.0 -o "/Users/alex/Documents/Built Projects/Deployment/DumpRenderTree" "-L/Users/alex/Documents/Built Projects/Deployment" "-F/Users/alex/Documents/Built Projects/Deployment" -filelist "/Users/alex/Documents/Built Projects/DumpRenderTree.build/Deployment/DumpRenderTree.build/Objects-normal/ppc/DumpRenderTree.LinkFileList" -framework WebKit -framework WebCore -framework JavaScriptCore -arch ppc -prebind
/usr/bin/ld: warning prebinding disabled because dependent library: /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit is not prebound
/usr/bin/ld: Undefined symbols:
.objc_class_name_NSAutoreleasePool
.objc_class_name_NSConstantString
.objc_class_name_NSDate
.objc_class_name_NSObject
.objc_class_name_NSRunLoop
.objc_class_name_NSURLRequest
_CFStringCreateWithCString
_CFURLCreateWithFileSystemPath
_NSDefaultRunLoopMode
__NSConstantStringClassReference
collect2: ld returned 1 exit status
** BUILD FAILED **
running css1/basic/class_as_selector testCan't exec "/Users/alex/Documents/Built Projects/DumpRenderTree": Permission denied at /System/Library/Perl/5.8.6/IPC/Open3.pm line 244.
open2: exec of /Users/alex/Documents/Built Projects/DumpRenderTree - failed at /usr/bin/run-webkit-tests line 112
 -> failed
running css1/basic/comments testBroken pipe

Thanks.

llama

 

[mkjellman]

i keep getting this:

blueberry:~ mkjellman$ WebKitTools/Scripts/build-webkit
/Users/mkjellman/final/libWebKitSystemInterface.a
deprecated option: -buildstyle is no longer supported in xcodebuild. Use -configuration instead.
(NOTE: project JavaScriptCore was written by an older version of Xcode (39) -- temporarily upgrading it to version 42 (without modifying project file))

=== BUILDING NATIVE TARGET dftables WITH CONFIGURATION Deployment ===

CompileC /Users/mkjellman/final/JavaScriptCore.build/Deployment/dftables.build/Objects-normal/ppc/dftables.o pcre/dftables.c normal ppc c com.apple.compilers.gcc.4_0
mkdir /Users/mkjellman/final/JavaScriptCore.build/Deployment/dftables.build/Objects-normal/ppc
cd /Users/mkjellman/JavaScriptCore
setenv MACOSX_DEPLOYMENT_TARGET 10.3
/usr/bin/gcc-4.0 -x c -arch ppc -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -g -Os -fmessage-length=0 -mtune=G4 -fvisibility=hidden -I/Users/mkjellman/final/JavaScriptCore.build/Deployment/dftables.build/dftables.hmap -mdynamic-no-pic -F/Users/mkjellman/final/Deployment -I/Users/mkjellman/final/Deployment/include -I/Users/mkjellman/final/JavaScriptCore.build/Deployment/dftables.build/DerivedSources -c /Users/mkjellman/JavaScriptCore/pcre/dftables.c -o /Users/mkjellman/final/JavaScriptCore.build/Deployment/dftables.build/Objects-normal/ppc/dftables.o
/Users/mkjellman/JavaScriptCore/pcre/dftables.c:45:19: error: ctype.h: No such file or directory
/Users/mkjellman/JavaScriptCore/pcre/dftables.c:46:19: error: stdio.h: No such file or directory
/Users/mkjellman/JavaScriptCore/pcre/dftables.c:47:20: error: string.h: No such file or directory
In file included from /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/include/syslimits.h:7,
from /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/include/limits.h:11,
from /Users/mkjellman/JavaScriptCore/pcre/internal.h:71,
from /Users/mkjellman/JavaScriptCore/pcre/dftables.c:49:
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/include/limits.h:122:61: error: limits.h: No such file or directory
In file included from /Users/mkjellman/JavaScriptCore/pcre/dftables.c:49:
/Users/mkjellman/JavaScriptCore/pcre/internal.h:74:20: error: stdlib.h: No such file or directory
In file included from /Users/mkjellman/JavaScriptCore/pcre/dftables.c:52:
/Users/mkjellman/JavaScriptCore/pcre/maketables.c: In function 'kjs_pcre_maketables':
/Users/mkjellman/JavaScriptCore/pcre/maketables.c:72: warning: incompatible implicit declaration of built-in function 'malloc'
/Users/mkjellman/JavaScriptCore/pcre/maketables.c:117: warning: incompatible implicit declaration of built-in function 'memset'
/Users/mkjellman/JavaScriptCore/pcre/maketables.c:155: warning: incompatible implicit declaration of built-in function 'strchr'
/Users/mkjellman/JavaScriptCore/pcre/dftables.c: In function 'main':
/Users/mkjellman/JavaScriptCore/pcre/dftables.c:60: warning: incompatible implicit declaration of built-in function 'printf'
** BUILD FAILED **

 

[Evangelion]

Is this related to that thing I read about the open source community saying Apple hadn't given much back regarding Safari? Or something like that anyway.

The situation you refer to went like this:

- Apple took KHTML rendering-engine from the KDE-project and built Safari around it. Note, this was perfectly legal for Apple to do, and KDE-developers were extatic over this move

- KDE-developers wanted to work with Apple, so that both groups could benefit from the joint efforts. They gave WebCore (as Apple's version of KHTML is called)-developers commit-access to KDE's CVS-servers. And, of course, WebCore-devels had access to KDE mailing-lists and bug-databases (like everyone does).

- Apple, however was not really interested in working with KDE-developers. KDE-developers asked for access to WebCore's bug-databse and code-management-system so they could track Apple's changes more closely, and they were willing to sign NDA's if needed. Apple was not interested.

- Apple did follow the requirements of KHTML's licese, and they released their changes to others. But their releases were next to useless to KDE-guys. Apple did not release individual patches, but one gigantic WebCore-tarball. Extracting meaningful improvements from that code proved to be exceedingly difficult. And since KDE-developers had no access to WebCores bug-database, they had no idea what changes with explanations like "this fixes bug #74553" meant. And since they had no access to the source-management-server, they could not observe how the code changed over time.

- KDE-developers let the matter be, since Apple was abiding by the license, although they might not had followed the spirit of the license.

- As time passed and KDE gained features/fixes that had been in Safari for a while (note: these improvements were usually re-written by the KDE-developers, since they could not really get them from WebCore due to reasons I mentioned earlier), users complained that KDE-developers were lazy and/or incompetent since it took them so long to implement the WebCore-improvements. KDE-developers did not comment on these accusations.

- When it was told that Safari passes the Acid2-test, some people started talking how KHTML should get these changes soon, since Apple is working with KDE-guys at improving KHTML. At that point one KDE-developers (Zack Rusin) told that Apple does not work with KDE. That there is no cooperation between KDE and Apple. Apple does get improvements from KDE-developers (since they can get changes straight from KDE's CVS), but KDE does not really get any improvements from Apple, since all they get is a periodical code-bomb in a form on a new WebCore-release. Note: He did not really blame Apple here. He explisitly mentioned that Apple is abiding by the license, but that they had made a desicion of not working with KDE. His message was really pointed towards the users who thought that Apple and KDE are working together.

- Several websites then started talking about the "issue", and painted it as KDE-developers were complaining about not getting code from Apple. But that was not the case. KDE-developers complained about the users who thought that Apple and KDE had a great thing going where they worked closely together to improve KHTML/WebCore. that was not the case, and they told that in public.

If you are interested, this is the blog-entry that started this all. I'm glad that Apple is now doing the right thing. Fact is that having KDE-developers and Apple-developers working more closely together (and this effort by Apple goes a long way towards achieving that!), benefits us all! It will result in rendering-engine that kicks more ass than WebCore/KHTML do today! !

 

[dubbz]

Evangelion: Here, have a cookie! That was a great summary!

 

[whooleytoo]

So... presumably someone could use this engine to make a Windows or Linux browser.

I've the code checked out at home, so I can't check it now, but it would depend on what the projects link against. Presumably they at least link against Foundation or CoreFoundation, meaning those would also need to be open sourced for this to be possible - unless Webkit works on top of GNUstep.

 

[whooleytoo]

Has anyone seen a mention of what version of Xcode is required?

The projects are Project Builder format, but I still can't open any of the project files in Xcode 1.5, didn't have any problems with Xcode 2.0.

 

[robbieduncan]

If you have updraded to XCode 2.1 (what do you mean it was only released on Monday?) you might want to read this. My builds with XCode 2.1 did not work without it.

Also the new WebKit crashes Safari if you open the Acid2 test (the actual test page) in a new tab for some reason!

 

[whooleytoo]

If you have updraded to XCode 2.1 (what do you mean it was only released on Monday?) you might want to read this. My builds with XCode 2.1 did not work without it.

Also the new WebKit crashes Safari if you open the Acid2 test (the actual test page) in a new tab for some reason!

Thanks! So it works on 2.0, and should now work on 2.1; but there's no mention of 1.x. I'm trying to avoid installing Tiger at work, but this doesn't give me much choice.

 

[NeoMayhem]

Wow, I just compiled the latest code and it is much faster then what ships with 10.4.1. Pages load and scroll much faster then before.

 

[mrzippy]

Well built it now, and worked 1st time

The Acid 2 test works, although the page before the test image has crashed Safari with a bus error a couple of times.

Anyway the latest build is faster

 

[Stridder44]

So does this mean that these builds will be put into the next versions of Safari and such? Or is this a completely independent thing?

It sounds awesome and exciting that people can already tell that Safari is way faster. I want to compile it but don't really know much on it all.

 

[kugino]

they have detailed instructions on building at macosxhints.com. i followed the instructions and am now working on the newly-built safari. acid2 test renders properly and scrolling is much much better. i'm limited by my connection speed (satellite) so can't say much about how fast pages load.

couple things i've noticed...your shell script needs to keep running if you want to keep using Safari with the new WebKit. i've made a simple Automator shell script application for this and that damn Workflow Running thing keeps running in the menubar. any ideas on how to get rid of this? also, i did get a couple of safari crashes while attempting to access the acid2 test. but things now seem to be running quite smoothly.

also, it took about 15 minutes to do the whole build from start to finish (downloading all the files to having the build completed) on my PM 2.0/2.5GB ram. not too shabby. took about twice as long on my 1Ghz iBook.

 

[wdlove]

Sounds like good news when we will be getting more work on Safari. Anything that will decrease beach balls or slowness of Safari will be welcomed.

 

[NeoMayhem]

So does this mean that these builds will be put into the next versions of Safari and such? Or is this a completely independent thing?

It sounds awesome and exciting that people can already tell that Safari is way faster. I want to compile it but don't really know much on it all.

Many of the updates will make it into the next version of safari. But sometimes speed increases make things less stable, so they are not included, even though most people will never have problems.