Bug 43621

Summary: [Qt] Build WebKit2 into a static lib
Product: WebKit Reporter: Balazs Kelemen <kbalazs>
Component: WebKit2Assignee: Balazs Kelemen <kbalazs>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, abecsi, commit-queue, eric, hausmann, koivisto, luiz, ossy, webkit.review.bot
Priority: P2 Keywords: Qt, QtTriaged
Version: 528+ (Nightly build)   
Hardware: PC   
OS: All   
Bug Depends on: 43671    
Bug Blocks:    
Attachments:
Description Flags
proposed patch
none
fixed patch none

Description Balazs Kelemen 2010-08-06 07:47:25 PDT
A separated build step for WebKit2 would help us keeping the build environment clean and effective. If WebKit2 would has it's own build step then we could handle the WebKit2Prefix.h file as a prefix header so we could avoid using precompiled header that brakes distcc. The other positive effect would be that identical file names in WebCore and WebKit2 would not cause a problem (currently the build is broken because we have a PluginView.cpp in WebKit2 and in WebCore as well).
Comment 1 Balazs Kelemen 2010-08-06 08:15:40 PDT
Created attachment 63724 [details]
proposed patch
Comment 2 Eric Seidel (no email) 2010-08-06 14:45:13 PDT
Comment on attachment 63724 [details]
proposed patch

rs=me.
Comment 3 Andras Becsi 2010-08-07 04:44:09 PDT
Comment on attachment 63724 [details]
proposed patch

Clearing flags on attachment: 63724

Committed r64904: <http://trac.webkit.org/changeset/64904>
Comment 4 Andras Becsi 2010-08-07 04:44:18 PDT
All reviewed patches have been landed.  Closing bug.
Comment 5 WebKit Review Bot 2010-08-07 04:55:27 PDT
http://trac.webkit.org/changeset/64904 might have broken Qt Windows 32-bit Release
Comment 6 Andras Becsi 2010-08-07 05:07:58 PDT
(In reply to comment #5)
> http://trac.webkit.org/changeset/64904 might have broken Qt Windows 32-bit Release
I'm investigating this issue.
Comment 7 Andras Becsi 2010-08-07 05:32:09 PDT
Had to rollout because of Qt Windows build breakage.
Comment 8 Balazs Kelemen 2010-08-07 09:35:50 PDT
Created attachment 63819 [details]
fixed patch

In the previous patch a portion from WebKit.pri was not moved to features.pri.
I believe that this was the reason of the build breakage.
Comment 9 Csaba Osztrogon√°c 2010-08-08 16:29:57 PDT
Reopen, because the previous patch was rolled out.
Comment 10 Antonio Gomes 2010-08-10 06:36:21 PDT
Comment on attachment 63819 [details]
fixed patch

r=me, given that simon already reviewed it and you fixed the win build regressin.
Comment 11 Andras Becsi 2010-08-10 06:52:06 PDT
Comment on attachment 63819 [details]
fixed patch

Clearing flags on attachment: 63819

Committed r65070: <http://trac.webkit.org/changeset/65070>
Comment 12 Andras Becsi 2010-08-10 06:52:16 PDT
All reviewed patches have been landed.  Closing bug.
Comment 13 WebKit Commit Bot 2010-08-10 07:07:09 PDT
Comment on attachment 63819 [details]
fixed patch

Rejecting patch 63819 from commit-queue.

Unexpected failure when processing patch!  Please file a bug against webkit-patch.
Failed to run "['./WebKitTools/Scripts/webkit-patch', '--status-host=queues.webkit.org', 'land-attachment', '--force-clean', '--build', '--non-interactive', '--ignore-builders', '--build-style=both', '--quiet', 63819, '--test', '--parent-command=commit-queue', '--no-update']" exit_code: 1
Last 500 characters of output:
.org/attachment.cgi?id=63819&action=edit
Fetching: https://bugs.webkit.org/show_bug.cgi?id=43621&ctype=xml
Processing 1 patch from 1 bug.
Cleaning working directory
Processing patch 63819 from bug 43621.
NOBODY (OOPS!) found in /Users/eseidel/Projects/CommitQueue/ChangeLog does not appear to be a valid reviewer according to committers.py.
ERROR: /Users/eseidel/Projects/CommitQueue/ChangeLog neither lists a valid reviewer nor contains the string "Unreviewed" or "Rubber stamp" (case insensitive).
Comment 14 WebKit Review Bot 2010-08-10 09:14:38 PDT
http://trac.webkit.org/changeset/65070 might have broken Qt Linux Release minimal
The following changes are on the blame list:
http://trac.webkit.org/changeset/65072
http://trac.webkit.org/changeset/65069
http://trac.webkit.org/changeset/65070
http://trac.webkit.org/changeset/65071
Comment 15 Luiz Agostini 2010-09-22 15:23:43 PDT
This breaks the build on macos as mac does not understand -whole-archive.

message:

ld: unknown option: -whole-archive
collect2: ld returned 1 exit status
Comment 16 Balazs Kelemen 2010-09-23 02:22:56 PDT
(In reply to comment #15)
> This breaks the build on macos as mac does not understand -whole-archive.
> 
> message:
> 
> ld: unknown option: -whole-archive
> collect2: ld returned 1 exit status

There should be an equivalent on mac. I know nothing about mac, so you should find somebody with the appropriate knowledge. I would like to track the issue in a separate bug.
Comment 17 Andras Becsi 2010-09-23 02:45:01 PDT
(In reply to comment #16)
> (In reply to comment #15)
> > This breaks the build on macos as mac does not understand -whole-archive.
> > 
> > message:
> > 
> > ld: unknown option: -whole-archive
> > collect2: ld returned 1 exit status
> 
> There should be an equivalent on mac. I know nothing about mac, so you should find somebody with the appropriate knowledge. I would like to track the issue in a separate bug.

Apple's libtool accepts the -all_load option, which should be equivalent to -whole-archive. There should be a conditional check in the project file.
IIRC Antti and Simon tried something in the past, I thought the fix already landed, seems it didn't.
Comment 18 Luiz Agostini 2010-10-05 06:26:30 PDT
(In reply to comment #16)
> (In reply to comment #15)
> > This breaks the build on macos as mac does not understand -whole-archive.
> > 
> > message:
> > 
> > ld: unknown option: -whole-archive
> > collect2: ld returned 1 exit status
> 
> There should be an equivalent on mac. I know nothing about mac, so you should find somebody with the appropriate knowledge. I would like to track the issue in a separate bug.

ok. fixed in bug 47167.