Bug 47377

Summary: [Qt] WebKit2 build scripts are buggy
Product: WebKit Reporter: Csaba Osztrogonác <ossy>
Component: Tools / TestsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Critical CC: abecsi, ademar, kbalazs, kenneth, sam, zoltan
Priority: P1 Keywords: Qt, QtTriaged
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
build log
none
proposed fix none

Description Csaba Osztrogonác 2010-10-07 13:49:02 PDT
Created attachment 70145 [details]
build log

It is an incremental build problem revealed by http://trac.webkit.org/changeset/69329 .
Clean build solved the build break, build log attached.
Comment 1 Csaba Osztrogonác 2010-10-11 05:09:50 PDT
Created attachment 70430 [details]
proposed fix
Comment 2 Csaba Osztrogonác 2010-10-11 05:32:14 PDT
My proposed patch will fix this build issue. 

But I have some questions. There are 7 generated message receivers
in WebKit2/DerivedSources.make, but only 3 in DerivedSources.pro.
Is there any reason why?

I guess Qt port of WebKit2 doesn't use them now. Andras, could you 
confirm? Will we need them for the future development? If yes, I 
propose we should add them to the build system and refactor/simplify 
generator rules in DerivedSources.pro. It would be great if we have 
only two generator rules: one for headers and one for sources.

Message receivers in DerivedSources.pro:
WebPage
WebPageProxy
WebProcess

Missing message receivers:
[r68170] PluginProcess
[r68309] PluginProcessProxy
[r68612] PluginProxy
[r68445] WebProcessConnection
Comment 3 Andreas Kling 2010-10-11 06:09:48 PDT
Comment on attachment 70430 [details]
proposed fix

LGTM
Comment 4 Csaba Osztrogonác 2010-10-11 06:19:23 PDT
Comment on attachment 70430 [details]
proposed fix

Clearing flags on attachment: 70430

Committed r69488: <http://trac.webkit.org/changeset/69488>
Comment 5 Csaba Osztrogonác 2010-10-11 06:19:34 PDT
All reviewed patches have been landed.  Closing bug.
Comment 6 Andras Becsi 2010-10-11 10:34:25 PDT
(In reply to comment #2)
> My proposed patch will fix this build issue. 
> 
> But I have some questions. There are 7 generated message receivers
> in WebKit2/DerivedSources.make, but only 3 in DerivedSources.pro.
> Is there any reason why?

Yes, we currently do not support plugins in separate processes yet.

> 
> I guess Qt port of WebKit2 doesn't use them now. Andras, could you 
> confirm? Will we need them for the future development? If yes, I 
> propose we should add them to the build system and refactor/simplify 
> generator rules in DerivedSources.pro. It would be great if we have 
> only two generator rules: one for headers and one for sources.

I totally agree, we should refactor the code generation as soon as possible, to make it less copy-paste prone.
Comment 7 Sam Weinig 2010-10-11 11:25:56 PDT
It would be great if you could use the DerivedSource.make file instead of your own.  I believe Qt uses DerivedSources.make in WebCore, is there a reason you can't here.  It would make my life easier.
Comment 8 Balazs Kelemen 2010-10-11 17:10:11 PDT
(In reply to comment #7)
> It would be great if you could use the DerivedSource.make file instead of your own.  I believe Qt uses DerivedSources.make in WebCore, is there a reason you can't here.  It would make my life easier.

We cannot use DerivedSources.make because it is chinese for qmake.
Qt uses only the .pri and .pro files. In WebCore we have a WebCore.pro
and a DerivedSources.pro as well as in WebKit2. We do not expect from 
you to handle fancy things like generator scripts in our build system but
I would like to ask you to inform us if you add such things to the
build system so we can handle that. Unfortunately our time zone has about
8 hours difference to your's so I cannot promise we are on IRC all
the time when it would be needed but if you add us to the cc list of 
such problematic patches or ping us on IRC when we are on then it would
be very helpful.
Here are the u-szeged guys who deals with the qtwebkit2 build:
ossy@webkit.org - Ossy
abecsi@webkit.org - bbandix
zoltan@webkit.org - Zoltan
kbalazs@webkit.org - kbalazs (me)
Comment 9 Csaba Osztrogonác 2010-10-12 05:57:35 PDT
(In reply to comment #7)
> It would be great if you could use the DerivedSource.make file instead of your own.  I believe Qt uses DerivedSources.make in WebCore, is there a reason you can't here.  It would make my life easier.

Unfortunately we can't use DerivedSources.make, because Qt is
cross-platform, and we can't expect that GNU make is available.

But we're going to simplify generator rules:
https://bugs.webkit.org/show_bug.cgi?id=47543
Comment 10 Kenneth Rohde Christiansen 2010-10-12 07:07:02 PDT
(In reply to comment #8)
> (In reply to comment #7)
> > It would be great if you could use the DerivedSource.make file instead of your own.  I believe Qt uses DerivedSources.make in WebCore, is there a reason you can't here.  It would make my life easier.
> 
> We cannot use DerivedSources.make because it is chinese for qmake.

It mut be possible to generate it from DerivedSource.make using a python script. Are you considering that?
Comment 11 Balazs Kelemen 2010-10-12 07:09:04 PDT
> It mut be possible to generate it from DerivedSource.make using a python script. Are you considering that?

No.
Comment 12 Kenneth Rohde Christiansen 2010-10-12 07:16:57 PDT
(In reply to comment #11)
> > It mut be possible to generate it from DerivedSource.make using a python script. Are you considering that?
> 
> No.

I mean... :-) Do you have anything against such a solution? what are the pros/cons? Or are there things that makes this extremely complicated?
Comment 13 Balazs Kelemen 2010-10-12 07:23:20 PDT
(In reply to comment #12)
> (In reply to comment #11)
> > > It mut be possible to generate it from DerivedSource.make using a python script. Are you considering that?
> > 
> > No.
> 
> I mean... :-) Do you have anything against such a solution? what are the pros/cons? Or are there things that makes this extremely complicated?

It does not makes sense to me to implementing a new meta-generator for that in
python. I have no knowledge in python. If somebody feel himself enough brave to
implement this, and the implementation is working properly then I am ok
with that.
Comment 14 Kenneth Rohde Christiansen 2010-10-12 07:25:10 PDT
Ademar, maybe that is something interesting for you to do?