Summary: | compile mismatch Cg/Cairo files (SVN 35180) | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Samuele Catuzzi <samuele_catuzzi> | ||||
Component: | SVG | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | bfulgham | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Attachments: |
|
Description
Samuele Catuzzi
2008-07-15 15:25:32 PDT
You'll notice from the quoted snippet of the project file that the CG files are set to be excluded from the build when the configuration Debug_Cairo or Release_Cairo is used. Are you building with one of those configurations? (In reply to comment #1) > You'll notice from the quoted snippet of the project file that the CG files are > set to be excluded from the build when the configuration Debug_Cairo or > Release_Cairo is used. Are you building with one of those configurations? > I simple compiled it with: WebKit/webKitTools/Scripts/build-webkit --cairo-win32 if I try to use set-webkit-configuration with release or debug those errors remain. Also as test, I tried to compile all sources without modify config.h and all worked fine but obviusually that was not a cairo build. * before every new compilation I cleaned WebKitBuild directory Which configuration does the build transcript show that it is building? Does it mention Debug, Release, Debug_Cairo, or Release_Cairo in the output? (In reply to comment #3) > Which configuration does the build transcript show that it is building? Does > it mention Debug, Release, Debug_Cairo, or Release_Cairo in the output? > This is my fault. It looks like it only works properly if you use the "--debug" or "--release" flags in conjunction with the "--cairo-win32". I'll correct the build script to handle this properly. (In reply to comment #4) > This is my fault. It looks like it only works properly if you use the > "--debug" or "--release" flags in conjunction with the "--cairo-win32". I'll > correct the build script to handle this properly. Just to clarify: If you use the command line: "build-webkit --release --cairo-win32", you get the correct "Release_Cairo" target. Likewise, if you use "build-webkit --debug --cairo-win32", you get the correct "Debug_Cairo" target. If you don't supply the --release/--debug argument, the script eventually falls back to Release, which then builds the wrong stuff for a Cairo build. This is why things work properly when you change the defines in the "config.h" file. (In reply to comment #5) in SVN 35180 If I try: WebKit/webKitTools/Scripts/build-webkit --release --cairo-win32 it require "qmake" command, the qmake into cygwin installation not work becouse it is an old one (qt3) so I installed newer "qt-win-opensource-4.4.0-mingw.exe" from trolltech site and than added "C:\Qt\4.4.0\bin" into my path. Now (even with svn35180) after "build-webkit --release --cairo-win32" the script say: *********start************ Subroutine main::tmpnam redefined at /home/admin/WebKit/WebKitTools/Scripts/webkitdirs.pm line 33 Subroutine main::tmpfile redefined at /home/admin/WebKit/WebKitTools/Scripts/webkitdirs.pm line 33 Checking mod-date of WebKitSupportLibrary.zip... Current WebKitSupportLibrary is up to date Calling 'qmake CONFIG+=qt-port -r OUTPUT_DIR=/home/admin/WebKit/WebKitBuild/Release_Cairo /home/admin/WebKit/WebKit.pro CONFIG+=release CONFIG-=debug' in /home/admin/WebKit/WebKitBuild/Release_Cairo Cannot find file: \home\admin\WebKit\WebKit.pro. Failed to setup build environment using qmake! **********end*********** But the file "WebKit.pro" is /home/admin/WebKit/WebKit.pro under windows it reside here C:\cygwin\home\admin\WebKit\WebKit.pro so I have found another problem :-) (In reply to comment #6) > it require "qmake" command, the qmake into cygwin installation not work becouse > it is an old one (qt3) so I installed newer "qt-win-opensource-4.4.0-mingw.exe" > from trolltech site and than added "C:\Qt\4.4.0\bin" into my path. > Now (even with svn35180) after "build-webkit --release --cairo-win32" the > script say: If you are being required to use qmake, something is terribly wrong. Neither the CG nor the Cairo builds require QMake for anything. (In reply to comment #7) > > If you are being required to use qmake, something is terribly wrong. Neither > the CG nor the Cairo builds require QMake for anything. > (even in 35180) If I remove "C:\Qt\4.4.0\bin" from my PATH the script say: $ WebKit/webKitTools/Scripts/build-webkit --release --cairo-win32 Subroutine main::tmpnam redefined at /home/admin/WebKit/WebKitTools/Scripts/webkitdirs.pm line 33 Subroutine main::tmpfile redefined at /home/admin/WebKit/WebKitTools/Scripts/webkitdirs.pm line 33 Checking mod-date of WebKitSupportLibrary.zip... Current WebKitSupportLibrary is up to date Can't exec "qmake": No such file or directory at /home/admin/WebKit/WebKitTools/Scripts/webkitdirs.pm line 736. Use of uninitialized value $mkspec in scalar chomp at /home/admin/WebKit/WebKitTools/Scripts/webkitdirs.pm line 736. Calling 'qmake CONFIG+=qt-port -r OUTPUT_DIR=/home/admin/WebKit/WebKitBuild/Release_Cairo /home/admin/WebKit/WebKit.pro CONFIG+=release CONFIG-=debug' in /home/admin/WebKit/WebKitBuild/Release_Cairo Can't exec "qmake": No such file or directory at /home/admin/WebKit/WebKitTools/Scripts/webkitdirs.pm line 856. Failed to setup build environment using qmake! (In reply to comment #8) for now, I found a solution of the "qmake" problem: If in your cygwin installation you have qt3* packages than when you try to build webkit for some obscure reasons it ask to you "qmake" command. To solve this problem simply run setup of cygwin and remove all qt3 packages, than run again Cygwin bash console and your problem disappear. I think that someone should update the http://trac.webkit.org/wiki/BuildingCairoOnWindows becouse at least config.h is changed Created attachment 22342 [details]
Extend default configuration handler to deal with Cairo case.
Comment on attachment 22342 [details]
Extend default configuration handler to deal with Cairo case.
Clearing the review flag as the bug is closed.
|