[webkit-dev] WebKit gtk saving Full Web Page Content to Image PNG/XBM

[satya kishan]

WebKit Team,

I am using the WebKit-gtk release r55959 I need to Save the Complete Web Page 
as Image PNG or any format. Is there any API to do this and on the Platform 
Linux Please Help in this regards.

thanks
satya



  
___
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

[Nikolas Zimmermann]

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

Re: [webkit-dev] CMake as a build system?

[Bill Hoffman]

> 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] CMake as a build system?

[Maciej Stachowiak]

On Apr 16, 2010, at 7:17 PM, Bill Hoffman wrote:

On Fri, Apr 16, 2010 at 10:10 PM, Marc-Antoine Ruel > 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?

[Bill Hoffman]

On Fri, Apr 16, 2010 at 10:04 PM, Adam Treat  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] currentTime() and UTC time

[Yong Li]

Just raised a bug for this. Except the usage in jsCurrentTime(), all calls
to currentTime() in both JavaScriptCore (threading, TimeoutChecker,
ProfileNode...) and WebCore (Timer, and many other cases...) are time
counting and assume it never goes backward. If we make currentTime() return
the system UTC time (like gettimeofday), then it will break time counting
when system time is changed (e.g. by calling settimeofday()), and give
unexpected results. If we make currentTime() always increase, then after
user changes system time, the browser cannot provide correct JS Date until
being restarted.

https://bugs.webkit.org/show_bug.cgi?id=37743



2010/4/16 Yong Li 

> 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] CMake as a build system?

[Bill Hoffman]

On Fri, Apr 16, 2010 at 10:10 PM, Marc-Antoine Ruel  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.

-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?

[Bill Hoffman]

>
> 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?

[Marc-Antoine Ruel]

2010/4/16 Marc-Antoine Ruel 

> 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 
>
> 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.
> :)
>

... and deprecate the prior build system!


>
> Not that my opinion counts at all.
>
> --
> M-A
>



-- 
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?

[Maciej Stachowiak]

On Apr 16, 2010, at 6:58 PM, Bill Hoffman wrote:

On Fri, Apr 16, 2010 at 9:45 PM, Maciej Stachowiak   
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.


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.


All I'm saying is that it's not *currently* installed out of the box  
on Mac OS X.




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


So by "installed" we're just talking about the fact that it's an  
executable, not a script?


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?

[Marc-Antoine Ruel]

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 

> 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?

[Adam Treat]

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?

[Bill Hoffman]

On Fri, Apr 16, 2010 at 9:57 PM, Nico Weber  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?

[Bill Hoffman]

On Fri, Apr 16, 2010 at 9:45 PM, Maciej Stachowiak  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] [webkit meeting notes] build systems

[Marc-Antoine Ruel]

2010/4/16 Nikolas Zimmermann 

>
> 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?

[Nico Weber]

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  wrote:
>
> On Apr 16, 2010, at 5:50 PM, Bill Hoffman wrote:
>
>> On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting 
>> wrote:
>>>
>>> On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak  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] CMake as a build system?

[Maciej Stachowiak]

On Apr 16, 2010, at 5:50 PM, Bill Hoffman wrote:

On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting   
wrote:
On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak   
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?

[Bill Hoffman]

On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting  wrote:
> On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak  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] python coding style, PEP-8, and 80-column line widths

[Dirk Pranke]

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  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  wrote:
>>
>> On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote:
>>
>>> 
>>>
>>> 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?

[Peter Kasting]

On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak  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] CMake as a build system?

[Maciej Stachowiak]

On Apr 16, 2010, at 3:25 PM, Adam Treat wrote:


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.


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.)


Regards,
Maciej

___
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

[Maciej Stachowiak]

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?

[Adam Treat]

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] CMake as a build system?

[Maciej Stachowiak]

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] python coding style, PEP-8, and 80-column line widths

[David Levin]

(I have contributed but not often.) I also agree with " 80 columns hurts
readability."

It doesn't take much looking to show a
lotof
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  wrote:

>
> On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote:
>
>  
>>
>> 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] python coding style, PEP-8, and 80-column line widths

[Maciej Stachowiak]

On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote:




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] CMake as a build system?

[Adam Treat]

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  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=8Ut9o4OdSC0&feature=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?

[Eric Seidel]

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  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=8Ut9o4OdSC0&feature=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?

[Adam Treat]

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=8Ut9o4OdSC0&feature=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] CMake as a build system?

[Bill Hoffman]

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=8Ut9o4OdSC0&feature=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

--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoff...@kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573
___
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

[Nikolas Zimmermann]

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] python coding style, PEP-8, and 80-column line widths

[Eric Seidel]

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



On Wed, Apr 14, 2010 at 5:02 PM, Dirk Pranke  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
http://

Re: [webkit-dev] Clean way to allow delegates for PopupMenu?

[Gustavo Sverzut Barbieri]

On Fri, Apr 16, 2010 at 11:21 AM, Luiz Agostini
 wrote:
> 2010/4/16 Gustavo Sverzut Barbieri 
>>
>> On Fri, Apr 16, 2010 at 10:30 AM, Luiz Agostini
>>  wrote:
>> >
>> > 2010/4/15 Gustavo Sverzut Barbieri 
>> >>
>> >> 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] [webkit meeting notes] build systems

[Nikolas Zimmermann]

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?

[Luiz Agostini]

2010/4/16 Gustavo Sverzut Barbieri 

> On Fri, Apr 16, 2010 at 10:30 AM, Luiz Agostini
>  wrote:
> >
> > 2010/4/15 Gustavo Sverzut Barbieri 
> >>
> >> 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] Clean way to allow delegates for PopupMenu?

[Gustavo Sverzut Barbieri]

On Fri, Apr 16, 2010 at 10:30 AM, Luiz Agostini
 wrote:
>
> 2010/4/15 Gustavo Sverzut Barbieri 
>>
>> 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?

[Luiz Agostini]

2010/4/15 Gustavo Sverzut Barbieri 

> 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.


>
> 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.

br
Luiz


>
> Regards,
>
> --
> 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
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Media elements meeting notes

[Alpha Lam]

2010年4月13日17:04 pnormand :

> On Tue, 2010-04-13 at 14:52 -0700, Eric Uhrhane wrote:
>
> > New topic: Loader.
> >
> > Things that would be improved by unifying loading between media elements
> and the
> > rest of webkit:
> >   Unified resource security model.
> >   Make application cache work for media.
> >   Make WebCore cache work for media, better cache balancing by unifying
> caching
> >   with that of the platform MediaEngine cache.
> >   Make Inspector work better for media.
> >   Make authentication work [cookies, referrer, http-auth].
> >   Easier to add new schemes [data://, file URNs], since it would work
> with all
> >   protocols supported by the loader.
> >
> > We have another list of requirements for the loader before it could be
> used.
> > Requirements and drawbacks of unification:
> >   Need to support non-web protocols such as rtsp.
> >   May need 2 code paths.
> >   Need to add byte-range and discontinuous cache support.
> >   Need to support files > 2GB.
> >   May be difficult to hook our loader into platform media engine.
> >   Some media engine's loaders are optimized for media playback
> heuristics; we'd
> >   need to match that behavior.
> >   Andrew: Threading limitations on resource loaders?
> >
> > Michael Nordman said something here about using ResourceHandle for this.
>  He can
> > flesh that out, as I didn't follow the discussion.
> >
>
> The GStreamer-based MediaPlayerPrivate has a source element in
> WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp that
> uses the WebCore infrastructure to load the resources from http(s)
> servers and feed the data into the gst pipeline. This way we can reuse
> the http session (cookies, referer, ...).
>
> We can probably use it for data: uris too (we currently have a specific src
> element
> for this).
>
> Philippe
>

I totally think we should do this instead of implementing resource loading
on each port. As a matter of fact, in Chromium we use ResourceHandle
directly and provides a layer of buffering and for doing range requests.
This allows us to support http:// https:// data://, cookies, referrer,
http-auth and even AppCache.

Unifying the resource loader also helps pushing a HTTP streaming standard. I
think this has great benefits, media resource loading is well within web
standard, basically just HTTP range requests, having a common code path that
handles buffering, caching and range requests will benefit all.

Alpha


>
> ___
> 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

[Peter Kasting]

On Fri, Apr 16, 2010 at 10:14 AM, Marc-Antoine Ruel wrote:

> For those who missed the session, please understand that what's Peter said
> isn't exactly what we agreed on.
>

I apologize for muddying the waters.

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

[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.

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 

> On Fri, Apr 16, 2010 at 8:42 AM, Kevin Ollivier 
> wrote:
>
>> 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] [webkit meeting notes] build systems

[Peter Kasting]

On Fri, Apr 16, 2010 at 8:42 AM, Kevin Ollivier wrote:

> 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

[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.

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

[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. 

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

[webkit-dev] currentTime() and UTC time

[Yong Li]

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

[Kevin Ollivier]

Hi Peter,

On Apr 15, 2010, at 9:42 PM, Peter Kasting wrote:

> On Thu, Apr 15, 2010 at 9:15 PM, Kevin Ollivier  
> 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

Re: [webkit-dev] [webkit meeting notes] build systems

[Nikolas Zimmermann]

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

[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.

Adam

On Friday 16 April 2010 12:42:01 am Peter Kasting wrote:
> On Thu, Apr 15, 2010 at 9:15 PM, Kevin Ollivier 
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?
> 
> 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