Re: [webkit-dev] [webkit meeting notes] build systems
I am very skeptical that it is feasible to write a gyp generator that would output QMake files. There is a log of magic in those QMake files. My sense is that it would not be trivial by any means. Plus, I don't like the idea of a meta-meta generators. Seems way to mickey- mouse to me. Adam On Friday 16 April 2010 12:42:01 am Peter Kasting wrote: On Thu, Apr 15, 2010 at 9:15 PM, Kevin Ollivier kev...@theolliviers.comwrote: Anyway, my $0.02 is that, in terms of immediate bang for the buck, we're probably better off trying to synchronize the build systems automatically in some way. My perception is that Qt developers will want to use qmake, GTK will want to use autotools, etc. and while some build systems could certainly be merged (e.g. as you say the Win and Mac projects for WebKit itself could be gyp-generated), I don't think we'll ever really narrow it down to one master system for a variety of reasons. I do, however, think we may be able to narrow the 'build system updating' process down to one step / one script that updates all ports simultaneously, and do so without too much effort. If I'm not mistaking you, that seems to be the route Evan is discussing, with his concrete proposal being to investigate the feasibility of making gyp be the mechanism by which various different build systems can be generated from a single place (rather than seven). Or is this not what you were saying? Since most build systems out there have their data stored in either XML or plain text, converting a build file list from one build system's data format to another is probably not more than a few hours of Python hacking, if that. Indeed, we already have MSVC/XCode/makefile generators for gyp, I would assume that given those, a generator for e.g. qmake wouldn't be hard. I really think someone should seriously consider investing some time and resources into improving this issue though, updating a build system doesn't take long but updating 7-10 build systems on almost a daily basis probably adds up to some pretty significant amount of time and energy that could probably be spent on better things. I think that is the shared viewpoint that has led to this discussion. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
Am 16.04.2010 um 16:44 schrieb Adam Treat: I am very skeptical that it is feasible to write a gyp generator that would output QMake files. There is a log of magic in those QMake files. My sense is that it would not be trivial by any means. Plus, I don't like the idea of a meta-meta generators. Seems way to mickey- mouse to me. Agreed to a certain degree. Using gyp/whatever to generate qmake files, to generate Makefile/Xcode files etc seems akward to me as well. What we really need to resolve is adding/removing files from compilation, that's the most common task that has to be done in 5+ build systems at the moment. So I have a new proposal: 1) Maintain a list of headers/source files to be compiled for ALL platforms (ie. dom/Node.cpp, etc..) 2) Keep all existing Makefile.am, WebCore.pro etc files as templates, ie. WebCore.pro.template, with a special variable somewhere marking the $$HEADER_LIST$$ and the $ $SOURCE_LIST$$ 3) Use a script that generates individual build files (eg. WebCore.pro) from WebCore.pro.template, it only needs to insert the file list with the correct syntax in the correct places 4) Keep all platform specific files to be compiled in the individual build system files (eg. WebCore.pro.template) I think we'll never find a consensus on a single build system, there are too many different needs. I only care about the most repetitive work in order to keep the build system up2date: adding/removing cross-platform files. Of course this is some kind of meta-meta build system, but we could also agree to move the template files in a WebCore/build-templates folder and run a update-project-files script after adding/remove files, that generates the build files, like WebCore.pro and commit them. This way only the person who added/removed a file from build would need to run that script, instead of every one, this would effectively hide the meta-meta build system. If we find an acceptable solution for just adding/removing cross- platform buildable files that it would already make me happy :-) Looking for comments! Niko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
Hi Peter, On Apr 15, 2010, at 9:42 PM, Peter Kasting wrote: On Thu, Apr 15, 2010 at 9:15 PM, Kevin Ollivier kev...@theolliviers.com wrote: Anyway, my $0.02 is that, in terms of immediate bang for the buck, we're probably better off trying to synchronize the build systems automatically in some way. My perception is that Qt developers will want to use qmake, GTK will want to use autotools, etc. and while some build systems could certainly be merged (e.g. as you say the Win and Mac projects for WebKit itself could be gyp-generated), I don't think we'll ever really narrow it down to one master system for a variety of reasons. I do, however, think we may be able to narrow the 'build system updating' process down to one step / one script that updates all ports simultaneously, and do so without too much effort. If I'm not mistaking you, that seems to be the route Evan is discussing, with his concrete proposal being to investigate the feasibility of making gyp be the mechanism by which various different build systems can be generated from a single place (rather than seven). Or is this not what you were saying? I was talking about something far more limited, like converting common build file lists from one format to another. Since most build systems out there have their data stored in either XML or plain text, converting a build file list from one build system's data format to another is probably not more than a few hours of Python hacking, if that. Indeed, we already have MSVC/XCode/makefile generators for gyp, I would assume that given those, a generator for e.g. qmake wouldn't be hard. Perhaps, but in any case, I think the first step there is for the Gyp developers to try implementing support and see how it goes. However, from that perspective, until Gyp has support for those formats, isn't a discussion about switching for other ports a bit premature on the WebKit side? i.e. that would be next steps for Gyp, not next steps for WebKit. I'd think Gyp would implement support for those formats and then come here and ask people to consider a switch. Obviously there is something to discuss on the WebKit / Win and WebKit / Mac side since Gyp can already handle those, but at least for the other ports I was thinking of something less involved than a build system migration of that nature (at least, in the sense of moving to it being auto-generated). My suggestion was about leaving the actual build system untouched but having it include a file (or having a script automatically replace a group of source files in the project file) with a generated list of common build files. More like a script that generates a patch for each build system when changes are made to common build files than auto-generating the whole project file(s). This way the ports can continue to work with and maintain their own build system, but when a common build file is added or removed, a script is run that makes a patch for all build systems. I think that would cover a vast majority of the manual hassle involved in managing the cross-platform build files. Regards, Kevin I really think someone should seriously consider investing some time and resources into improving this issue though, updating a build system doesn't take long but updating 7-10 build systems on almost a daily basis probably adds up to some pretty significant amount of time and energy that could probably be spent on better things. I think that is the shared viewpoint that has led to this discussion. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] currentTime() and UTC time
Hi All The default implementation of JS Date is calling currentTime() (by jsCurrentTime()), so it assumes currentTime() returns current UTC time, and system UTC time can be changed. However, currentTime() is also used in most cases as a system tick count, which means it should always be monotonically increasing. I guess we should remove the dependency on currentTime() from JS Date to fix the confliction. Any idea? -Yong ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
Hi Nikolas, On Apr 16, 2010, at 8:09 AM, Nikolas Zimmermann wrote: Am 16.04.2010 um 16:44 schrieb Adam Treat: I am very skeptical that it is feasible to write a gyp generator that would output QMake files. There is a log of magic in those QMake files. My sense is that it would not be trivial by any means. Plus, I don't like the idea of a meta-meta generators. Seems way to mickey- mouse to me. Agreed to a certain degree. Using gyp/whatever to generate qmake files, to generate Makefile/Xcode files etc seems akward to me as well. What we really need to resolve is adding/removing files from compilation, that's the most common task that has to be done in 5+ build systems at the moment. So I have a new proposal: 1) Maintain a list of headers/source files to be compiled for ALL platforms (ie. dom/Node.cpp, etc..) 2) Keep all existing Makefile.am, WebCore.pro etc files as templates, ie. WebCore.pro.template, with a special variable somewhere marking the $$HEADER_LIST$$ and the $$SOURCE_LIST$$ 3) Use a script that generates individual build files (eg. WebCore.pro) from WebCore.pro.template, it only needs to insert the file list with the correct syntax in the correct places 4) Keep all platform specific files to be compiled in the individual build system files (eg. WebCore.pro.template) I think we'll never find a consensus on a single build system, there are too many different needs. I only care about the most repetitive work in order to keep the build system up2date: adding/removing cross-platform files. Of course this is some kind of meta-meta build system, but we could also agree to move the template files in a WebCore/build-templates folder and run a update-project-files script after adding/remove files, that generates the build files, like WebCore.pro and commit them. This way only the person who added/removed a file from build would need to run that script, instead of every one, this would effectively hide the meta-meta build system. If we find an acceptable solution for just adding/removing cross-platform buildable files that it would already make me happy :-) Correct me if I'm wrong, but I thought it would actually be possible to have the values for HEADER_LIST and SOURCE_LIST set in a separate file, and that Qt and GTK build systems could then just include that file. This way we could avoid using templates and such. Just add the included file to the tree (e.g. WebCore/sources.inc) and have the Qt and GTK projects include WebCore/sources.inc and reference those variables. As I mentioned earlier, I actually coded up something using this approach a long time ago back when wx was still using Bakefile, but I guess it never caught the attention of projects like Qt as I never got any feedback on it. (Or maybe the idea was just so obviously flawed somehow. :) Here's the script: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/update-sources-list.py It would probably not take long at all to have getWebCoreFilesDict pull from a gyp project, XCode project, or whatever we wanted to use as the master file list that should be updated. Thoughts? Thanks, Kevin Looking for comments! Niko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
This seems like just a more restricted version of gyp to me. And one that isn't sufficiently powerful, e.g., what if a platform decides to disable SVG and doesn't want to compile SVG files? You end up adding some sort of syntax for that. In the end, you have something that's 90% of the way to a gyp file and now we have yet another build system. Whether the build file generation happens when you sync versus when the person adding the file makes the change is also flexible with gyp. We could very well use gyp to generate the build files for each platform and check that in. I don't actually think that's a good idea though. The risk of build files and gyp files getting out of sync is not worth it. Ojan On Fri, Apr 16, 2010 at 8:09 AM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Am 16.04.2010 um 16:44 schrieb Adam Treat: I am very skeptical that it is feasible to write a gyp generator that would output QMake files. There is a log of magic in those QMake files. My sense is that it would not be trivial by any means. Plus, I don't like the idea of a meta-meta generators. Seems way to mickey- mouse to me. Agreed to a certain degree. Using gyp/whatever to generate qmake files, to generate Makefile/Xcode files etc seems akward to me as well. What we really need to resolve is adding/removing files from compilation, that's the most common task that has to be done in 5+ build systems at the moment. So I have a new proposal: 1) Maintain a list of headers/source files to be compiled for ALL platforms (ie. dom/Node.cpp, etc..) 2) Keep all existing Makefile.am, WebCore.pro etc files as templates, ie. WebCore.pro.template, with a special variable somewhere marking the $$HEADER_LIST$$ and the $$SOURCE_LIST$$ 3) Use a script that generates individual build files (eg. WebCore.pro) from WebCore.pro.template, it only needs to insert the file list with the correct syntax in the correct places 4) Keep all platform specific files to be compiled in the individual build system files (eg. WebCore.pro.template) I think we'll never find a consensus on a single build system, there are too many different needs. I only care about the most repetitive work in order to keep the build system up2date: adding/removing cross-platform files. Of course this is some kind of meta-meta build system, but we could also agree to move the template files in a WebCore/build-templates folder and run a update-project-files script after adding/remove files, that generates the build files, like WebCore.pro and commit them. This way only the person who added/removed a file from build would need to run that script, instead of every one, this would effectively hide the meta-meta build system. If we find an acceptable solution for just adding/removing cross-platform buildable files that it would already make me happy :-) Looking for comments! Niko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
On Fri, Apr 16, 2010 at 8:42 AM, Kevin Ollivier kev...@theolliviers.comwrote: Perhaps, but in any case, I think the first step there is for the Gyp developers to try implementing support and see how it goes. However, from that perspective, until Gyp has support for those formats, isn't a discussion about switching for other ports a bit premature on the WebKit side? i.e. that would be next steps for Gyp, not next steps for WebKit. I'd think Gyp would implement support for those formats and then come here and ask people to consider a switch. Which is basically what we're proposing here. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
Please guys, No need to speculate here on what I proposed at the session since Evan somehow left some details out and let me reinforce some points. For those who missed the session, please understand that what's Peter said isn't exactly what we agreed on. Here's some data points: - No plan to generate qtmake or makefile.am or whatever else - No plan to force anyone to switch - No plan (for now) to get any automatic file list for the checkout (some build system do that) - No plan for any template based project generation - Making a new fully functional backend to gyp *is* involved. It's a big deal. There's no use in a 95% done build system. The rough proposal is: - De-chromify most .gyp and .gypi files currently living in webkit.org, split the files off as necessary in the process to untangle conditions. - With coordination with aroben, look at implementing a faithful copy of apple's win port, with a potential switch over *if it works out*. No guarantee. - Some people expressed interest into generating the file list to their build system and having the build system import the generated project files. That wouldn't be a complete backend implementation. Obviously, complete backend implementation at http://code.google.com/p/gyp are welcome as long as they have unit tests. What you can do *only if you want*: - Extract the file list of your port project into a single simple file and have your build system import this file. I'm not talking about pushing anyone's back and I have *no intention* to. So unless you want to actively submit patches towards the proposal, please let this thread die, it's an unproductive use of my time. I don't plan to do that in the very short term as I have other things on my plate, I'll definitely do this incrementally. M-A 2010/4/16 Peter Kasting pkast...@google.com On Fri, Apr 16, 2010 at 8:42 AM, Kevin Ollivier kev...@theolliviers.comwrote: Perhaps, but in any case, I think the first step there is for the Gyp developers to try implementing support and see how it goes. However, from that perspective, until Gyp has support for those formats, isn't a discussion about switching for other ports a bit premature on the WebKit side? i.e. that would be next steps for Gyp, not next steps for WebKit. I'd think Gyp would implement support for those formats and then come here and ask people to consider a switch. Which is basically what we're proposing here. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- M-A ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Clean way to allow delegates for PopupMenu?
On Fri, Apr 16, 2010 at 10:30 AM, Luiz Agostini
luiz.agost...@openbossa.org wrote:
2010/4/15 Gustavo Sverzut Barbieri barbi...@profusion.mobi
Hello all,
I'm part of the EFL port team and we're implementing the PopupMenu,
however EFL is a different platform as for our port it is just a
state-full canvas, not relying on any widget set/toolkit, we do not
have the concept of a menu at all!
Looking at all existing implementations, they all go straight to
native platform menus. But we can't as we want to avoid such
dependencies. What we'd like to have is a delegate, that WebCore calls
the ChromeClient that is overloaded in WebKit, giving our View user a
callback with all data.
The good news is: we did it and it works quite well.
The bad news is: we cheated and include WebKit/efl/WebCoreSupport from
PopupMenuEfl.cpp, what a shame! (although some ports *cough qt*
include in WebCore defines from WebKit)
In Qt we have an abstract class for popup delegates in WebCore/platform/qt
and we do the actual popup delegate implementation in
WebKit/qt/WebCoreSupport. The delegates are implemented in WebKit layer and
PopupMenuQt has no knowledge about any specific delegates. The only reason
to include WebKit/qt/WebCoreSupport in PopupMenuQt is to make the call that
creates the delegate object. It could be avoided adding a method to Chrome
but at the time I was working on it it was decided that it was not needed.
Yes, it is kinda similar to our, since we looked at your
implementation before doing our. But the problem here is you still
include WebKit files from WebCore. For *me* it looks like a hack, but
if people do not complain then I can kindly keep it as is, after all
it is working already :-)
In order to have a clean design, we'd like to know the general opinion
on how to do it. From what I see Mac already defines a similar call in
ChromeClient.h:
#if PLATFORM(MAC)
...
virtual void willPopUpMenu(NSMenu *) { }
#endif
in our case, we'd need:
#if PLATFORM(EFL)
virtual void showPopupMenu(const IntRect rect, FrameView*
view, int index) { }
virtual void hidePopupMenu() { }
#endif
so our PopupMenuEfl.cpp will just proxy to these calls.
However, although Mac does that it may not be the best solution, so to
avoid endless patches to be discussed at bugzilla I'd like to know
your opinion on the best way so our patch is right from beginning.
I think that we could add methods to Chrome and ChromeClient to create the
delegates. For example:
PopupMenuDelegate* Chrome::createPopupMenuDelegate(PopupMenuClient* c) {
return m_client-createPopupMenuDelegate(c); }
virtual PopupMenuDelegate*
ChromeClient::createPopupMenuDelegate(PopupMenuClient*) { return 0; }
Each port could then provide its typedef for PopupMenuDelegate and
override ChromeClient::createPopupMenuDelegate.
Well, as I said we just need methods to show/hide to keep it done, but
if you want to implement another class PopupMenuDelegate to do it,
then we could do such work as well. We'd like to avoid this delegate
class as our port is C, so we'd need to do it all in C++ plus what we
have done in C already, just to proxy it.
BR,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Clean way to allow delegates for PopupMenu?
2010/4/16 Gustavo Sverzut Barbieri barbi...@profusion.mobi
On Fri, Apr 16, 2010 at 10:30 AM, Luiz Agostini
luiz.agost...@openbossa.org wrote:
2010/4/15 Gustavo Sverzut Barbieri barbi...@profusion.mobi
Hello all,
I'm part of the EFL port team and we're implementing the PopupMenu,
however EFL is a different platform as for our port it is just a
state-full canvas, not relying on any widget set/toolkit, we do not
have the concept of a menu at all!
Looking at all existing implementations, they all go straight to
native platform menus. But we can't as we want to avoid such
dependencies. What we'd like to have is a delegate, that WebCore calls
the ChromeClient that is overloaded in WebKit, giving our View user a
callback with all data.
The good news is: we did it and it works quite well.
The bad news is: we cheated and include WebKit/efl/WebCoreSupport from
PopupMenuEfl.cpp, what a shame! (although some ports *cough qt*
include in WebCore defines from WebKit)
In Qt we have an abstract class for popup delegates in
WebCore/platform/qt
and we do the actual popup delegate implementation in
WebKit/qt/WebCoreSupport. The delegates are implemented in WebKit layer
and
PopupMenuQt has no knowledge about any specific delegates. The only
reason
to include WebKit/qt/WebCoreSupport in PopupMenuQt is to make the call
that
creates the delegate object. It could be avoided adding a method to
Chrome
but at the time I was working on it it was decided that it was not
needed.
Yes, it is kinda similar to our, since we looked at your
implementation before doing our. But the problem here is you still
include WebKit files from WebCore. For *me* it looks like a hack, but
if people do not complain then I can kindly keep it as is, after all
it is working already :-)
In order to have a clean design, we'd like to know the general opinion
on how to do it. From what I see Mac already defines a similar call in
ChromeClient.h:
#if PLATFORM(MAC)
...
virtual void willPopUpMenu(NSMenu *) { }
#endif
in our case, we'd need:
#if PLATFORM(EFL)
virtual void showPopupMenu(const IntRect rect, FrameView*
view, int index) { }
virtual void hidePopupMenu() { }
#endif
so our PopupMenuEfl.cpp will just proxy to these calls.
However, although Mac does that it may not be the best solution, so to
avoid endless patches to be discussed at bugzilla I'd like to know
your opinion on the best way so our patch is right from beginning.
I think that we could add methods to Chrome and ChromeClient to create
the
delegates. For example:
PopupMenuDelegate* Chrome::createPopupMenuDelegate(PopupMenuClient* c) {
return m_client-createPopupMenuDelegate(c); }
virtual PopupMenuDelegate*
ChromeClient::createPopupMenuDelegate(PopupMenuClient*) { return 0; }
Each port could then provide its typedef for PopupMenuDelegate and
override ChromeClient::createPopupMenuDelegate.
Well, as I said we just need methods to show/hide to keep it done, but
if you want to implement another class PopupMenuDelegate to do it,
then we could do such work as well. We'd like to avoid this delegate
class as our port is C, so we'd need to do it all in C++ plus what we
have done in C already, just to proxy it.
I did not suggest a class for PopupMenuDelegate: Each port could then
provide its typedef for PopupMenuDelegate.
Remember PlatformWidget? :-)
BR,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
Am 16.04.2010 um 18:26 schrieb Ojan Vafai: This seems like just a more restricted version of gyp to me. And one that isn't sufficiently powerful, e.g., what if a platform decides to disable SVG and doesn't want to compile SVG files? You end up adding some sort of syntax for that. In the end, you have something that's 90% of the way to a gyp file and now we have yet another build system. Ermm, we have ENABLE(SVG) blocks around all SVG related files. That was not a good example, as those platforms may just compile the SVG* files, they are just empty. So no need to add any syntax for that. That applies to all other features as well - we _always_ compile all files, not depending on any setting. Cheers, Niko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Clean way to allow delegates for PopupMenu?
On Fri, Apr 16, 2010 at 11:21 AM, Luiz Agostini
luiz.agost...@openbossa.org wrote:
2010/4/16 Gustavo Sverzut Barbieri barbi...@profusion.mobi
On Fri, Apr 16, 2010 at 10:30 AM, Luiz Agostini
luiz.agost...@openbossa.org wrote:
2010/4/15 Gustavo Sverzut Barbieri barbi...@profusion.mobi
Hello all,
I'm part of the EFL port team and we're implementing the PopupMenu,
however EFL is a different platform as for our port it is just a
state-full canvas, not relying on any widget set/toolkit, we do not
have the concept of a menu at all!
Looking at all existing implementations, they all go straight to
native platform menus. But we can't as we want to avoid such
dependencies. What we'd like to have is a delegate, that WebCore calls
the ChromeClient that is overloaded in WebKit, giving our View user a
callback with all data.
The good news is: we did it and it works quite well.
The bad news is: we cheated and include WebKit/efl/WebCoreSupport from
PopupMenuEfl.cpp, what a shame! (although some ports *cough qt*
include in WebCore defines from WebKit)
In Qt we have an abstract class for popup delegates in
WebCore/platform/qt
and we do the actual popup delegate implementation in
WebKit/qt/WebCoreSupport. The delegates are implemented in WebKit layer
and
PopupMenuQt has no knowledge about any specific delegates. The only
reason
to include WebKit/qt/WebCoreSupport in PopupMenuQt is to make the call
that
creates the delegate object. It could be avoided adding a method to
Chrome
but at the time I was working on it it was decided that it was not
needed.
Yes, it is kinda similar to our, since we looked at your
implementation before doing our. But the problem here is you still
include WebKit files from WebCore. For *me* it looks like a hack, but
if people do not complain then I can kindly keep it as is, after all
it is working already :-)
In order to have a clean design, we'd like to know the general opinion
on how to do it. From what I see Mac already defines a similar call in
ChromeClient.h:
#if PLATFORM(MAC)
...
virtual void willPopUpMenu(NSMenu *) { }
#endif
in our case, we'd need:
#if PLATFORM(EFL)
virtual void showPopupMenu(const IntRect rect, FrameView*
view, int index) { }
virtual void hidePopupMenu() { }
#endif
so our PopupMenuEfl.cpp will just proxy to these calls.
However, although Mac does that it may not be the best solution, so to
avoid endless patches to be discussed at bugzilla I'd like to know
your opinion on the best way so our patch is right from beginning.
I think that we could add methods to Chrome and ChromeClient to create
the
delegates. For example:
PopupMenuDelegate* Chrome::createPopupMenuDelegate(PopupMenuClient* c) {
return m_client-createPopupMenuDelegate(c); }
virtual PopupMenuDelegate*
ChromeClient::createPopupMenuDelegate(PopupMenuClient*) { return 0; }
Each port could then provide its typedef for PopupMenuDelegate and
override ChromeClient::createPopupMenuDelegate.
Well, as I said we just need methods to show/hide to keep it done, but
if you want to implement another class PopupMenuDelegate to do it,
then we could do such work as well. We'd like to avoid this delegate
class as our port is C, so we'd need to do it all in C++ plus what we
have done in C already, just to proxy it.
I did not suggest a class for PopupMenuDelegate: Each port could then
provide its typedef for PopupMenuDelegate.
Remember PlatformWidget? :-)
yes, but we still need the hide to get it hidden :-)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths
bike-shedding
I think 80 columns is a waste of time and hurts readability.
Instead of being smart about when we wrap code, 80 adheres to a
blanket rule, discourages long variable/function names, and needlessly
expands code vertically ignoring modern wider-than-long monitors.
The optparse code which was recently re-wrapped is one example of 80c
fail. Impossible to tell in the wrapped version which arguments are
actually being listed (first argument to the function) because your
eye can't parse the start of each line.
That said. I'd rather have you and Adam and Chris all working on the
Python than have folks lose interest due to code wrapping. If the
consensus is 80c, I'll learn to deal. :)
The choice is either:
A. no wrapping rule to match the rest of WebKit
B. 80c to match the official PEP8 spec (and Google code).
I've chosen A. in the past. Mostly to match my own personal bias I'm sure.
-eric
/bike-shedding
On Wed, Apr 14, 2010 at 5:02 PM, Dirk Pranke dpra...@chromium.org wrote:
Hi all,
As I'm sure the discussions in the webkit meeting over the past two
days made clear, it looks like most of our non-C++ code is getting
written in Python. Back in January, Adam Barth posted this thread [1]
where I thought it was agreed we would attempt to follow PEP 8 ([2] -
the standard Python style guide) faithfully.
The one (somewhat) controversial aspect of that style guide is that it
requires a 79-column wide line length.
More recently, as part of implementing a style checker for Python code
[3], some have advocated that we should not follow that particular
restriction, because (a) the WebKit C++ style guide does not follow
that restriction, and (b) there is a reasonable amount of Python code
that does not follow the rule today and would have to be brought into
compliance. In particular, it was asked that we disable the long-line
check until at least the existing code was brought into compliance.
As far as (b) goes, there are currently (as of r57510) 1533 long lines
out of the 35,616 lines found under WebKitTools/Scripts/webkitpy,
occurring in 120 out 193 .py files. Most of the files that have any
long lines have less than five [4].
As far as disabling the check goes, I rather firmly believe that if we
wish to follow an ~80 column line-length limitation, the check needs
to be on by default, or else those who aren't used to this convention
will not follow it and the problem will get worse, not better (as
evidenced by [5]).
So, do we want to follow an 80-column limit for Python code, or not,
and if we do, should we enforce the rule by default or not?
If the concern is the existing code base I also (reluctantly)
volunteer to fix the long lines, if that influences the decisions.
Although I personally believe that code that is less than 80 columns
wide is easier to read and easier to maintain for a variety of
reasons, I mostly volunteer to do this because it's just not many
lines of code and I believe that having style guidelines that aren't
followed are a Very Bad Thing and hence the fact that we have existing
violations is a bad reason in this case to argue for not following the
rule.
Note that I do not particularly wish to argue the merits of this
particular style choice, just make (and document) a decision. It's a
religious position and the interweb is littered with existing
arguments pro and con that we would likely just rehash here. I raise
the issue at all only because I had thought that we made a decision
and then it was changed in relative obscurity in a bug, rather than
after being discussed here, whch struck me as not the right way to do
this sort of thing.
-- Dirk
[1] https://lists.webkit.org/pipermail/webkit-dev/2010-January/011423.html
[2] http://www.python.org/dev/peps/pep-0008/
[3] https://bugs.webkit.org/show_bug.cgi?id=33639
[4] Stats:
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | wc -l # 193 .py files
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | xargs wc -l # 35,316 lines of code
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | xargs awk '{ if (length($0) 79) printf(%s:%d %s\n,
FILENAME, FNR, $0);}' # all of the long lines
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | xargs awk '{ if (length($0) 79) printf(%s\n, FILENAME);}'
| sort | uniq -c | wc -l # 120 files w/ long lines
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | xargs awk '{ if (length($0) 79) printf(%s\n, FILENAME);}'
| sort | uniq -c # distribution by file
[5] https://bugs.webkit.org/show_bug.cgi?id=37586
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
Re: [webkit-dev] [webkit meeting notes] build systems
Am 16.04.2010 um 19:14 schrieb Marc-Antoine Ruel: Please guys, No need to speculate here on what I proposed at the session since Evan somehow left some details out and let me reinforce some points. For those who missed the session, please understand that what's Peter said isn't exactly what we agreed on. What you can do only if you want: - Extract the file list of your port project into a single simple file and have your build system import this file. I'm not talking about pushing anyone's back and I have no intention to. So unless you want to actively submit patches towards the proposal, please let this thread die, it's an unproductive use of my time. I don't plan to do that in the very short term as I have other things on my plate, I'll definitely do this incrementally. This thread is not only about what you may have proposed in the meeting. Please reread the other mails of the thread. I'm really a bit astonished, reading statments like your last sentences above. It's not very polite to state you don't care about other opinions and call that an unproductive use of your time. Cheers, Niko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Friday 16 April 2010 05:10:25 pm Bill Hoffman wrote: Hi, Adam Treat (tr...@kde.org) suggested that I join this list to talk about CMake as an option for a unified cross platform build solution. My name is Bill Hoffman. I am the lead CMake developer. My company Kitware created and supports CMake. I think CMake would have a lot to offer the WebKit developers. If you are not familiar with CMake, I did a google tech talk in December which can be found here: http://www.youtube.com/watch?v=8Ut9o4OdSC0feature=youtube_gdata Another article about how KDE switched to CMake can be found here: Why the KDE project switched to CMake -- and how http://lwn.net/Articles/188693/ If you are interested in moving to CMake, I would be interested in helping. If you have any questions about CMake, fire away! Thanks. -Bill I asked Bill to introduce himself here because I think CMake represents the best hope for WebKit to find a way out of the current build system proliferation we are experiencing. Of the meta-buildsystems in existence I think CMake is by far the most powerful and mature. CMake is by far the most widespread and supported. It is already used successfully by Open Source projects of a comparable scope to WebKit and with similar cross-platform needs: LLVM, KDE, Boost. I know that WebKit already has GYP and QMake meta-buildsystems, but to my knowledge both are inferior to CMake. In fact, I do not think CMake is lacking in any important way to the features of GYP. What's more, the WebKit project has already had a CMake based buildsystem. This is what the 'Unity' nascent QtWebkit port used originally. I think we should re-introduce it and seriously consider using CMake as a cross-platform solution to our build system proliferation issues. I highly encourage you all to view the google tech talk above as it gives a great introduction to CMake. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
I don't see this as a decision needing pre-approval. This is a decision needing code. No one has tried to make Mac, Win, or other ports use a common system yet. Obviously converting them in the end requires buy-in from those ports. But producing a demo doesn't/shouldn't. I eventually plan to look at this task. When I do, I'll take a peek at CMake. Someone just needs to sit down and build something. Then we can make an informed decision. -eric On Fri, Apr 16, 2010 at 2:29 PM, Adam Treat tr...@kde.org wrote: On Friday 16 April 2010 05:10:25 pm Bill Hoffman wrote: Hi, Adam Treat (tr...@kde.org) suggested that I join this list to talk about CMake as an option for a unified cross platform build solution. My name is Bill Hoffman. I am the lead CMake developer. My company Kitware created and supports CMake. I think CMake would have a lot to offer the WebKit developers. If you are not familiar with CMake, I did a google tech talk in December which can be found here: http://www.youtube.com/watch?v=8Ut9o4OdSC0feature=youtube_gdata Another article about how KDE switched to CMake can be found here: Why the KDE project switched to CMake -- and how http://lwn.net/Articles/188693/ If you are interested in moving to CMake, I would be interested in helping. If you have any questions about CMake, fire away! Thanks. -Bill I asked Bill to introduce himself here because I think CMake represents the best hope for WebKit to find a way out of the current build system proliferation we are experiencing. Of the meta-buildsystems in existence I think CMake is by far the most powerful and mature. CMake is by far the most widespread and supported. It is already used successfully by Open Source projects of a comparable scope to WebKit and with similar cross-platform needs: LLVM, KDE, Boost. I know that WebKit already has GYP and QMake meta-buildsystems, but to my knowledge both are inferior to CMake. In fact, I do not think CMake is lacking in any important way to the features of GYP. What's more, the WebKit project has already had a CMake based buildsystem. This is what the 'Unity' nascent QtWebkit port used originally. I think we should re-introduce it and seriously consider using CMake as a cross-platform solution to our build system proliferation issues. I highly encourage you all to view the google tech talk above as it gives a great introduction to CMake. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
Sure. Having Bill's and Kitware's help will hopefully make it easier to produce such a demo using CMake. I pledge to help. We can start with this: http://trac.webkit.org/log/trunk/CMakeLists.txt?rev=17853 Cheers, Adam On Friday 16 April 2010 05:34:45 pm Eric Seidel wrote: I don't see this as a decision needing pre-approval. This is a decision needing code. No one has tried to make Mac, Win, or other ports use a common system yet. Obviously converting them in the end requires buy-in from those ports. But producing a demo doesn't/shouldn't. I eventually plan to look at this task. When I do, I'll take a peek at CMake. Someone just needs to sit down and build something. Then we can make an informed decision. -eric On Fri, Apr 16, 2010 at 2:29 PM, Adam Treat tr...@kde.org wrote: On Friday 16 April 2010 05:10:25 pm Bill Hoffman wrote: Hi, Adam Treat (tr...@kde.org) suggested that I join this list to talk about CMake as an option for a unified cross platform build solution. My name is Bill Hoffman. I am the lead CMake developer. My company Kitware created and supports CMake. I think CMake would have a lot to offer the WebKit developers. If you are not familiar with CMake, I did a google tech talk in December which can be found here: http://www.youtube.com/watch?v=8Ut9o4OdSC0feature=youtube_gdata Another article about how KDE switched to CMake can be found here: Why the KDE project switched to CMake -- and how http://lwn.net/Articles/188693/ If you are interested in moving to CMake, I would be interested in helping. If you have any questions about CMake, fire away! Thanks. -Bill I asked Bill to introduce himself here because I think CMake represents the best hope for WebKit to find a way out of the current build system proliferation we are experiencing. Of the meta-buildsystems in existence I think CMake is by far the most powerful and mature. CMake is by far the most widespread and supported. It is already used successfully by Open Source projects of a comparable scope to WebKit and with similar cross-platform needs: LLVM, KDE, Boost. I know that WebKit already has GYP and QMake meta-buildsystems, but to my knowledge both are inferior to CMake. In fact, I do not think CMake is lacking in any important way to the features of GYP. What's more, the WebKit project has already had a CMake based buildsystem. This is what the 'Unity' nascent QtWebkit port used originally. I think we should re-introduce it and seriously consider using CMake as a cross-platform solution to our build system proliferation issues. I highly encourage you all to view the google tech talk above as it gives a great introduction to CMake. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths
On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote: bike-shedding I think 80 columns is a waste of time and hurts readability. Instead of being smart about when we wrap code, 80 adheres to a blanket rule, discourages long variable/function names, and needlessly expands code vertically ignoring modern wider-than-long monitors. The optparse code which was recently re-wrapped is one example of 80c fail. Impossible to tell in the wrapped version which arguments are actually being listed (first argument to the function) because your eye can't parse the start of each line. That said. I'd rather have you and Adam and Chris all working on the Python than have folks lose interest due to code wrapping. If the consensus is 80c, I'll learn to deal. :) The choice is either: A. no wrapping rule to match the rest of WebKit B. 80c to match the official PEP8 spec (and Google code). I've chosen A. in the past. Mostly to match my own personal bias I'm sure. I haven't contributed to WebKit's Python code yet, but I will say that I agree with Eric's sentiments here. 80-column limit is archaic and pointless. No one is developing WebKit on a vt220. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths
(I have contributed but not often.) I also agree with 80 columns hurts readability. It doesn't take much looking to show a lothttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py#L135of lineshttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py#L259 thathttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py#L305 demonstratehttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py#L326 thishttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/rebaseline_chromium_webkit_tests.py#L449. However, I understand the desire to just take PEP8 whole. Once you decide to throw away one item, why not argue about any other (I tend to think 80 columns is the only thing that should be thrown out.) Sincerely, dc86ed7c29395f2b0863967f5350dfca4151be9d On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote: bike-shedding I think 80 columns is a waste of time and hurts readability. Instead of being smart about when we wrap code, 80 adheres to a blanket rule, discourages long variable/function names, and needlessly expands code vertically ignoring modern wider-than-long monitors. The optparse code which was recently re-wrapped is one example of 80c fail. Impossible to tell in the wrapped version which arguments are actually being listed (first argument to the function) because your eye can't parse the start of each line. That said. I'd rather have you and Adam and Chris all working on the Python than have folks lose interest due to code wrapping. If the consensus is 80c, I'll learn to deal. :) The choice is either: A. no wrapping rule to match the rest of WebKit B. 80c to match the official PEP8 spec (and Google code). I've chosen A. in the past. Mostly to match my own personal bias I'm sure. I haven't contributed to WebKit's Python code yet, but I will say that I agree with Eric's sentiments here. 80-column limit is archaic and pointless. No one is developing WebKit on a vt220. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Apr 16, 2010, at 2:45 PM, Adam Treat wrote: Sure. Having Bill's and Kitware's help will hopefully make it easier to produce such a demo using CMake. I pledge to help. We can start with this: http://trac.webkit.org/log/trunk/CMakeLists.txt?rev=17853 Can CMake generate native Xcode and Visual Studio project files? There are some people who consider it important to be able to edit, build and debug in the IDE. Can it handle generated sources well? I think those are the two toughest problems for any candidate unified build system. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Friday 16 April 2010 06:21:39 pm Maciej Stachowiak wrote: On Apr 16, 2010, at 2:45 PM, Adam Treat wrote: Sure. Having Bill's and Kitware's help will hopefully make it easier to produce such a demo using CMake. I pledge to help. We can start with this: http://trac.webkit.org/log/trunk/CMakeLists.txt?rev=17853 Can CMake generate native Xcode and Visual Studio project files? There are some people who consider it important to be able to edit, build and debug in the IDE. Can it handle generated sources well? It was designed to do precisely that :) Bill can speak to this, but the google tech talk gives a great overview. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
On Apr 16, 2010, at 8:09 AM, Nikolas Zimmermann wrote: Am 16.04.2010 um 16:44 schrieb Adam Treat: I am very skeptical that it is feasible to write a gyp generator that would output QMake files. There is a log of magic in those QMake files. My sense is that it would not be trivial by any means. Plus, I don't like the idea of a meta-meta generators. Seems way to mickey- mouse to me. Agreed to a certain degree. Using gyp/whatever to generate qmake files, to generate Makefile/Xcode files etc seems akward to me as well. What we really need to resolve is adding/removing files from compilation, that's the most common task that has to be done in 5+ build systems at the moment. Besides adding, removing and renaming, the other thing that's really hard is adding a new generated source rule. Although this is not needed as frequently, I think anyone adding a new code generator script that has to work across all WebKit ports would have a hellish time of it right now. If I had to do it myself, I would just skip any ports that don't use DerivedSources.make. So I have a new proposal: 1) Maintain a list of headers/source files to be compiled for ALL platforms (ie. dom/Node.cpp, etc..) 2) Keep all existing Makefile.am, WebCore.pro etc files as templates, ie. WebCore.pro.template, with a special variable somewhere marking the $$HEADER_LIST$$ and the $ $SOURCE_LIST$$ 3) Use a script that generates individual build files (eg. WebCore.pro) from WebCore.pro.template, it only needs to insert the file list with the correct syntax in the correct places 4) Keep all platform specific files to be compiled in the individual build system files (eg. WebCore.pro.template) I think we'll never find a consensus on a single build system, there are too many different needs. I only care about the most repetitive work in order to keep the build system up2date: adding/removing cross-platform files. I think the proposal above does not handle the derived sources problem. It also doesn't handle files that are shared between multiple ports but not all ports. It also doesn't provide project files that are directly usable by IDEs, on platforms where that is the standard way to do development. Once we start solving problems like that, I suspect we end up with something closer in complexity to Gyp or CMake. Regards, Maciej Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak m...@apple.com wrote: I'm curious if the Chromium folks who created Gyp had any specific reason that they ruled out CMake as an option. (I have heard that it was considered and rejected.) CCing a couple people involved if they wish to answer. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths
I think having longer lines of code hurts readability. There is lots of typographic evidence to back this up ( e.g. http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.2/. Of course, the typographic commentary applies to text rather than code, and most text isn't indented, but I still think it's right). Even where the monitors are wider than they are tall argument goes, I prefer to use that space for multiple columns of text, because even if you do allow 80 char lines, most lines are shorter and hence you have a lot of wasted space. Granted, it is a combination of factors. I come from a C-based lineage of 2-space indentation, short variable names, and 8-character function names. Those all combine to make an 80- character line length workable. People who come from a 4-space (or greater) indentation, and the long variable-names style of Java or C++-with-templates will tend to see things differently. -- Dirk On Fri, Apr 16, 2010 at 3:09 PM, David Levin le...@chromium.org wrote: (I have contributed but not often.) I also agree with 80 columns hurts readability. It doesn't take much looking to show a lot of lines that demonstrate this. However, I understand the desire to just take PEP8 whole. Once you decide to throw away one item, why not argue about any other (I tend to think 80 columns is the only thing that should be thrown out.) Sincerely, dc86ed7c29395f2b0863967f5350dfca4151be9d On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote: bike-shedding I think 80 columns is a waste of time and hurts readability. Instead of being smart about when we wrap code, 80 adheres to a blanket rule, discourages long variable/function names, and needlessly expands code vertically ignoring modern wider-than-long monitors. The optparse code which was recently re-wrapped is one example of 80c fail. Impossible to tell in the wrapped version which arguments are actually being listed (first argument to the function) because your eye can't parse the start of each line. That said. I'd rather have you and Adam and Chris all working on the Python than have folks lose interest due to code wrapping. If the consensus is 80c, I'll learn to deal. :) The choice is either: A. no wrapping rule to match the rest of WebKit B. 80c to match the official PEP8 spec (and Google code). I've chosen A. in the past. Mostly to match my own personal bias I'm sure. I haven't contributed to WebKit's Python code yet, but I will say that I agree with Eric's sentiments here. 80-column limit is archaic and pointless. No one is developing WebKit on a vt220. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting pkast...@google.com wrote: On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak m...@apple.com wrote: I'm curious if the Chromium folks who created Gyp had any specific reason that they ruled out CMake as an option. (I have heard that it was considered and rejected.) I belive I can answer that. During my talk at google, I met with with Mark Mentovai and talked to him about Gyp and CMake. The main thing that he was trying to avoid was the requirement that CMake be installed for the build. That is true, CMake does have to be installed. However, CMake is installed on more an more systems. The cmake.org site has about 2K downloads per day, and most linux distros include CMake. With KDE using CMake, it has become pretty easy to get. Apple is also using CMake for the LLVM project, so it should be installed and accepted at Apple. I worked with Doug Gregor of the LLVM team to help him convince the Apple testing folks to allow for CMake to be installed. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Apr 16, 2010, at 5:50 PM, Bill Hoffman wrote: On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting pkast...@google.com wrote: On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak m...@apple.com wrote: I'm curious if the Chromium folks who created Gyp had any specific reason that they ruled out CMake as an option. (I have heard that it was considered and rejected.) I belive I can answer that. During my talk at google, I met with with Mark Mentovai and talked to him about Gyp and CMake. The main thing that he was trying to avoid was the requirement that CMake be installed for the build. That is true, CMake does have to be installed. However, CMake is installed on more an more systems. The cmake.org site has about 2K downloads per day, and most linux distros include CMake. With KDE using CMake, it has become pretty easy to get. Apple is also using CMake for the LLVM project, so it should be installed and accepted at Apple. I worked with Doug Gregor of the LLVM team to help him convince the Apple testing folks to allow for CMake to be installed. FWIW, I don't have CMake installed, and I have everything a typical Apple developer would have and then some. I'm running SnowLeopard and the latest Xcode. CMake is also not installed by default on Windows and I am not sure if it comes with the cygwin distribution we use. When you say installed, does that mean it *has* to be in some system location? Could it be installed somewhere in the WebKit build tree? Our scripts download certain needed tools and libraries by default, so at least from the WebKit POV this is not necessarily a showstopper. Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? And finally, I'd still like to hear from the Chromium folks whether there were any other issues. This one seems fairly minor. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
This is from an earlier thread on this issue on webkit-dev: We also considered CMake, and had it demonstrably working for some of our smaller projects as well. Unfortunately, transitioning to CMake would have required moving everything over at once, without allowing for some existing projects to be maintained by hand during a transition period. CMake-generated files contain absolute paths, so a .tar or .zip of the source tree could not be primed with CMake output, complicating the bootstrapping process for new contributors. A less significant factor was that CMake introduced an additional binary build prerequisite, which would have had to have been installed everywhere. Python is already a prerequisite for Chromium, so a Python tool was easier to deploy. Nico (I'm not involved with gyp at all, I just remembered that old thread) On Fri, Apr 16, 2010 at 6:45 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 16, 2010, at 5:50 PM, Bill Hoffman wrote: On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting pkast...@google.com wrote: On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak m...@apple.com wrote: I'm curious if the Chromium folks who created Gyp had any specific reason that they ruled out CMake as an option. (I have heard that it was considered and rejected.) I belive I can answer that. During my talk at google, I met with with Mark Mentovai and talked to him about Gyp and CMake. The main thing that he was trying to avoid was the requirement that CMake be installed for the build. That is true, CMake does have to be installed. However, CMake is installed on more an more systems. The cmake.org site has about 2K downloads per day, and most linux distros include CMake. With KDE using CMake, it has become pretty easy to get. Apple is also using CMake for the LLVM project, so it should be installed and accepted at Apple. I worked with Doug Gregor of the LLVM team to help him convince the Apple testing folks to allow for CMake to be installed. FWIW, I don't have CMake installed, and I have everything a typical Apple developer would have and then some. I'm running SnowLeopard and the latest Xcode. CMake is also not installed by default on Windows and I am not sure if it comes with the cygwin distribution we use. When you say installed, does that mean it *has* to be in some system location? Could it be installed somewhere in the WebKit build tree? Our scripts download certain needed tools and libraries by default, so at least from the WebKit POV this is not necessarily a showstopper. Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? And finally, I'd still like to hear from the Chromium folks whether there were any other issues. This one seems fairly minor. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
2010/4/16 Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de Am 16.04.2010 um 19:14 schrieb Marc-Antoine Ruel: Please guys, No need to speculate here on what I proposed at the session since Evan somehow left some details out and let me reinforce some points. For those who missed the session, please understand that what's Peter said isn't exactly what we agreed on. What you can do *only if you want*: - Extract the file list of your port project into a single simple file and have your build system import this file. I'm not talking about pushing anyone's back and I have *no intention* to. So unless you want to actively submit patches towards the proposal, please let this thread die, it's an unproductive use of my time. I don't plan to do that in the very short term as I have other things on my plate, I'll definitely do this incrementally. This thread is not only about what you may have proposed in the meeting. Please reread the other mails of the thread. I'm really a bit astonished, reading statments like your last sentences above. It's not very polite to state you don't care about other opinions and call that an unproductive use of your time. Cheers, Niko Sorry, I didn't mean to be blunt but we did wear the PM hat and decide AI at the session. Chromium folks did look at CMake in the past, I'll add comments related to this build system to the other thread. -- M-A ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Fri, Apr 16, 2010 at 9:45 PM, Maciej Stachowiak m...@apple.com wrote: FWIW, I don't have CMake installed, and I have everything a typical Apple developer would have and then some. I'm running SnowLeopard and the latest Xcode. CMake is also not installed by default on Windows and I am not sure if it comes with the cygwin distribution we use. It can come with cygwin, and nothing is installed on Windows by default, not even the compiler... Macports has CMake, and of course we have binaries at cmake.org. When you say installed, does that mean it *has* to be in some system location? Could it be installed somewhere in the WebKit build tree? Our scripts download certain needed tools and libraries by default, so at least from the WebKit POV this is not necessarily a showstopper. It can be installed anywhere. There are binaries for all marjor OS's on www.cmake.org. It is setup to run from any directory, so you don't need root or anything to install. http://www.cmake.org/cmake/resources/software.html Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? It has to be installed, if this is a show stopper, then it is a show stopper. And finally, I'd still like to hear from the Chromium folks whether there were any other issues. This one seems fairly minor. I would as well. :) -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Fri, Apr 16, 2010 at 9:57 PM, Nico Weber tha...@chromium.org wrote: This is from an earlier thread on this issue on webkit-dev: We also considered CMake, and had it demonstrably working for some of our smaller projects as well. Unfortunately, transitioning to CMake would have required moving everything over at once, without allowing for some existing projects to be maintained by hand during a transition period. CMake-generated files contain absolute paths, so a .tar or .zip of the source tree could not be primed with CMake output, complicating the bootstrapping process for new contributors. A less significant factor was that CMake introduced an additional binary build prerequisite, which would have had to have been installed everywhere. Python is already a prerequisite for Chromium, so a Python tool was easier to deploy. I think you could do it part way. CMake has a new feature called external_project that allows you to download/configure/build packages using any build system. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Friday 16 April 2010 09:58:17 pm Bill Hoffman wrote: Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? It has to be installed, if this is a show stopper, then it is a show stopper. To be clear, it just has to be in the path, right? Which I think could be managed ;) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
Thanks Nico for digging up the archive. As I said in the other thread, the people at the session mostly looked about reducing the number of build system, not forcing anyone to use any tool. If some teams wants to switch to CMake, prefect as long as the number of build tool reduces. Nobody seemed willing to switch to qtmake. Nobody at the meeting advocated for CMake. I don't have first-hand experience about CMake but from I only heard midly negative comments. The generated xcodeproj and vcproj are far from 'native' and from f2f discussion, at least one llvm guy isn't happy about CMake and would rather move it off. The 'native' IDE feel was very high in our priority list, especially in XCode in fact. 2010/4/16 Adam Treat tr...@kde.org On Friday 16 April 2010 09:58:17 pm Bill Hoffman wrote: Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? It has to be installed, if this is a show stopper, then it is a show stopper. To be clear, it just has to be in the path, right? Which I think could be managed ;) I don't know if anyone really cares about the requirement of having another tool installed on the system or not as an hinderance, I don't mind. So in the end, if some team want to switch to CMake, just check-in stuff. :) Not that my opinion counts at all. -- M-A ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
We can make binaries available through a convenient download script (possibly one that gets a source drop and builds it) if we have to. In fact, when WebKit first switched to Subversion, for a while you had to get your own copy to even check out the tree. Sounds good. All I'm saying is that it's not *currently* installed out of the box on Mac OS X. Sure. So by installed we're just talking about the fact that it's an executable, not a script? Yes, it is a binary. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Fri, Apr 16, 2010 at 10:04 PM, Adam Treat tr...@kde.org wrote: On Friday 16 April 2010 09:58:17 pm Bill Hoffman wrote: Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? It has to be installed, if this is a show stopper, then it is a show stopper. To be clear, it just has to be in the path, right? Which I think could be managed ;) No, it is much more than the path. CMake needs to be around during the build, and at configure time. It does system introspection, also with the makefiles it includes a depend generator. So, to be clear, you have to install and run CMake on the machine where you are building the software. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Apr 16, 2010, at 7:17 PM, Bill Hoffman wrote: On Fri, Apr 16, 2010 at 10:10 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Thanks Nico for digging up the archive. As I said in the other thread, the people at the session mostly looked about reducing the number of build system, not forcing anyone to use any tool. If some teams wants to switch to CMake, prefect as long as the number of build tool reduces. Nobody seemed willing to switch to qtmake. Nobody at the meeting advocated for CMake. I don't have first-hand experience about CMake but from I only heard midly negative comments. The generated xcodeproj and vcproj are far from 'native' and from f2f discussion, at least one llvm guy isn't happy about CMake and would rather move it off. The 'native' IDE feel was very high in our priority list, especially in XCode in fact. It is as native as we can make it. However, we do call cmake during the build at some points, to overcome shortfalls of the build tool. Also, to re-run cmake if any of the input files change. Also, basic system commands like cp can be done with cmake -E copy_file so it is portable. Calling cmake during the build would likely be a showstopper for the Mac port. As far as I know, Apple's build farm does not have CMake installed (at least not on older build trains). And it's not easy to convince the build engineers to install custom build tools. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
Calling cmake during the build would likely be a showstopper for the Mac port. As far as I know, Apple's build farm does not have CMake installed (at least not on older build trains). And it's not easy to convince the build engineers to install custom build tools. I am told they have it now for LLVM. But, I do not work for Apple, so I can not verify that. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
Am 16.04.2010 um 18:14 schrieb Kevin Ollivier: Hi Nikolas, On Apr 16, 2010, at 8:09 AM, Nikolas Zimmermann wrote: Am 16.04.2010 um 16:44 schrieb Adam Treat: I am very skeptical that it is feasible to write a gyp generator that would output QMake files. There is a log of magic in those QMake files. My sense is that it would not be trivial by any means. Plus, I don't like the idea of a meta-meta generators. Seems way to mickey- mouse to me. Agreed to a certain degree. Using gyp/whatever to generate qmake files, to generate Makefile/Xcode files etc seems akward to me as well. What we really need to resolve is adding/removing files from compilation, that's the most common task that has to be done in 5+ build systems at the moment. So I have a new proposal: 1) Maintain a list of headers/source files to be compiled for ALL platforms (ie. dom/Node.cpp, etc..) 2) Keep all existing Makefile.am, WebCore.pro etc files as templates, ie. WebCore.pro.template, with a special variable somewhere marking the $$HEADER_LIST$$ and the $ $SOURCE_LIST$$ 3) Use a script that generates individual build files (eg. WebCore.pro) from WebCore.pro.template, it only needs to insert the file list with the correct syntax in the correct places 4) Keep all platform specific files to be compiled in the individual build system files (eg. WebCore.pro.template) I think we'll never find a consensus on a single build system, there are too many different needs. I only care about the most repetitive work in order to keep the build system up2date: adding/removing cross-platform files. Of course this is some kind of meta-meta build system, but we could also agree to move the template files in a WebCore/build-templates folder and run a update-project-files script after adding/remove files, that generates the build files, like WebCore.pro and commit them. This way only the person who added/removed a file from build would need to run that script, instead of every one, this would effectively hide the meta-meta build system. If we find an acceptable solution for just adding/removing cross- platform buildable files that it would already make me happy :-) Correct me if I'm wrong, but I thought it would actually be possible to have the values for HEADER_LIST and SOURCE_LIST set in a separate file, and that Qt and GTK build systems could then just include that file. This way we could avoid using templates and such. Just add the included file to the tree (e.g. WebCore/sources.inc) and have the Qt and GTK projects include WebCore/sources.inc and reference those variables. As I mentioned earlier, I actually coded up something using this approach a long time ago back when wx was still using Bakefile, but I guess it never caught the attention of projects like Qt as I never got any feedback on it. (Or maybe the idea was just so obviously flawed somehow. :) Here's the script: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/update-sources-list.py It would probably not take long at all to have getWebCoreFilesDict pull from a gyp project, XCode project, or whatever we wanted to use as the master file list that should be updated. Hi Kevin, I think that solution could work, though when reading through the other mails, especially Maciejs mail regarding the generated-source files, this solution probably is just too simple. I also take back my proposal, I didn't have certain things in mind when writing it, especially not the generated sources.. We do need something more sophisticated. Have a nice day, Niko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
