RESOLVED FIXED 43621
[Qt] Build WebKit2 into a static lib
https://bugs.webkit.org/show_bug.cgi?id=43621
Summary [Qt] Build WebKit2 into a static lib
Balazs Kelemen
Reported Friday, August 6, 2010 3:47:25 PM UTC
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).
Attachments
proposed patch (47.42 KB, patch)
2010-08-06 08:15 PDT, Balazs Kelemen
no flags
fixed patch (45.90 KB, patch)
2010-08-07 09:35 PDT, Balazs Kelemen
no flags
Balazs Kelemen
Comment 1 Friday, August 6, 2010 4:15:40 PM UTC
Created attachment 63724 [details] proposed patch
Eric Seidel (no email)
Comment 2 Friday, August 6, 2010 10:45:13 PM UTC
Comment on attachment 63724 [details] proposed patch rs=me.
Andras Becsi
Comment 3 Saturday, August 7, 2010 12:44:09 PM UTC
Comment on attachment 63724 [details] proposed patch Clearing flags on attachment: 63724 Committed r64904: <http://trac.webkit.org/changeset/64904>
Andras Becsi
Comment 4 Saturday, August 7, 2010 12:44:18 PM UTC
All reviewed patches have been landed. Closing bug.
WebKit Review Bot
Comment 5 Saturday, August 7, 2010 12:55:27 PM UTC
http://trac.webkit.org/changeset/64904 might have broken Qt Windows 32-bit Release
Andras Becsi
Comment 6 Saturday, August 7, 2010 1:07:58 PM UTC
(In reply to comment #5) > http://trac.webkit.org/changeset/64904 might have broken Qt Windows 32-bit Release I'm investigating this issue.
Andras Becsi
Comment 7 Saturday, August 7, 2010 1:32:09 PM UTC
Had to rollout because of Qt Windows build breakage.
Balazs Kelemen
Comment 8 Saturday, August 7, 2010 5:35:50 PM UTC
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.
Csaba Osztrogonác
Comment 9 Monday, August 9, 2010 12:29:57 AM UTC
Reopen, because the previous patch was rolled out.
Antonio Gomes
Comment 10 Tuesday, August 10, 2010 2:36:21 PM UTC
Comment on attachment 63819 [details] fixed patch r=me, given that simon already reviewed it and you fixed the win build regressin.
Andras Becsi
Comment 11 Tuesday, August 10, 2010 2:52:06 PM UTC
Comment on attachment 63819 [details] fixed patch Clearing flags on attachment: 63819 Committed r65070: <http://trac.webkit.org/changeset/65070>
Andras Becsi
Comment 12 Tuesday, August 10, 2010 2:52:16 PM UTC
All reviewed patches have been landed. Closing bug.
WebKit Commit Bot
Comment 13 Tuesday, August 10, 2010 3:07:09 PM UTC
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).
WebKit Review Bot
Comment 14 Tuesday, August 10, 2010 5:14:38 PM UTC
Luiz Agostini
Comment 15 Wednesday, September 22, 2010 11:23:43 PM UTC
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
Balazs Kelemen
Comment 16 Thursday, September 23, 2010 10:22:56 AM UTC
(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.
Andras Becsi
Comment 17 Thursday, September 23, 2010 10:45:01 AM UTC
(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.
Luiz Agostini
Comment 18 Tuesday, October 5, 2010 2:26:30 PM UTC
(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.
Note You need to log in before you can comment on or make changes to this bug.