[webkit-dev] Peripheral ports (was Re: WebKit Wishes)

2013-01-31 Thread noam . rosenthal


From: ext Eric Seidel e...@webkit.orgmailto:e...@webkit.org

I wish we didn’t have to worry about platforms we couldn’t test.

It can’t be the job of the core maintainers to care about all the peripheral 
ports which contribute very little core code. Our code needs to be structured 
in such a manner that its easy for the core to march forward, while letting the 
ports catch up as they need to asynchronously.  Platform support code shouldn’t 
even need to be in webkit.orghttp://webkit.org!  Porting 
webkit.orghttp://webkit.org’s platform abstractions should be trivial, but 
core developers (which probably 90% of them use only 2 ports Mac WK2 + Chromium 
Linux) shouldn’t need to worry about keeping all ports working.
As someone who works on the peripheral ports quite a bit I would have to 
agree that this is not a good situation. I would prefer a situation where my 
core contributions are considered valuable, and my peripheral ports 
contribution are not considered taxing.

 I wish we only had one build system
I think that having one meta-build system might help this quite a bit.
But what would really help me is if I could have a better understanding of 
which parts of the code are taxing for Apple and Google. For example, in 2011 
Oliver Hunt has communicated that the Qt JSC bindings were too taxing, and ever 
since we've done a lot of work to reduce that tax 
(https://bugs.webkit.org/show_bug.cgi?id=60842). This was, to me, a productive 
communication about that problem.

 I wish I felt like reviewers understood/trusted each other more.
I think that if there was a clear and detailed communication about taxing 
properties of the peripheral ports or platform abstraction, perhaps in the 
form of bugs on bugzilla like the one I've mentioned, we can trust the 
contributors from the peripheral ports, together with everyone else, to find 
the right solutions.
How would it feel for people if we had something like a bugzilla 
component/topic to track those issues?

I think that solving those issues rather than pushing the peripheral ports to 
the side is in the benefit of the WebKit project, and is one of the things that 
differentiates it from projects like Mozilla that only support one company's 
browser(s). I'm hoping that other people see this value as well…

~Noam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Hajime Morrita
(From the right address)

I did it for WTF and JSC with kevino@.
https://bugs.webkit.org/show_bug.cgi?id=72855
I hope I had had time to extend the work to WebCore, which was my original
goal :-/

I did it through an automation but the tool was so slow and hacky that it
was not capable for large WebCore codebase.

Seeing that the number of exported symbol is about 2700, manual work with
regular expression will also work
if it is OK to do the work incrementally... and if you are patient enough
:-)

--
morrita



On Thu, Jan 31, 2013 at 4:39 PM, Ryosuke Niwa ryosuke.n...@gmail.comwrote:

 On Wed, Jan 30, 2013 at 11:33 PM, Jochen Eisinger joc...@chromium.orgwrote:

 On Thu, Jan 31, 2013 at 1:15 AM, Maciej Stachowiak m...@apple.com wrote:

 On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote:

  On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote:
  Thanks for sharing this.
 
  On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:
 
  I wish we only had one build system (it were easy to add/remove/move
 files).
 
  I believe changes like http://trac.webkit.org/changeset/74849 are an
  unhealthy sign for the project.  Adam is not the only person who has
 chosen
  to empty files instead of removing them.  The pain of updating 8 build
  system is so great, we jump through hoops to avoid it.  Which means
 it took
  us months to move JavaScriptCore/wtf to WTF, and will take us years
 to kill
  WebCore/platform.
 
 
  +1
 
  This is a hard problem.  It is a problem worth solving.
 
  Do you have more thoughts on this, particularly since you know quite
 well
  how both Xcode and gyp work?
 
  I suspect this is one of those things that it would be hard to achieve
  consensus on since there are so many stakeholders.  But it may be
 fruitful
  to have a what if discussion about what this might look like.
 
 
  I think we can solve this problem if we agree that we want to. I think
  we haven't in the past mostly because we couldn't reach a consensus
  that it was worth solving enough to really try.
 
  I would love to see this fixed and would be glad to work on it. I
  think we should at least pursue this far enough to fully understand
  what our options are and what the costs and tradeoffs might be; does
  anyone disagree, and is anyone else willing to help pitch in?
 
  I think there are several possible ways we could solve this. One would
  be to switch to a common meta-build system. My understanding is that
  Apple's internal production build processes impose certain constraints
  here that I don't fully understand, but I know we've discussed the
  possibility of checking in generated project files as a workaround.
  Maybe there are other options as well to those constraints? I would
  love to discuss this further w/ someone from Apple ...

 It's far simplest for us if:
 (a) There is an Xcode project (or a Makefile) that builds the Mac port
 checked in to source control.
 (b) The generated project invokes only tools that are part of the
 default Mac OS X install.


 Another desirable property would be to move to a more automatic way of
 handling exported symbols: Currently each port that depends on this feature
 has its own .exp file or similar. I think if we could move to something
 that would allow for changing WebCore API without having to touch all those
 files, e.g. by consistently using WEBCORE_EXPORT macros would be a big win


 morrita already did this for WTF, and it works great for us. What's
 blocking us from doing the same for WebCore?

 - R. Niwa


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Ryosuke Niwa
On Thu, Jan 31, 2013 at 12:09 AM, Hajime Morrita morr...@google.com wrote:

 I did it for WTF and JSC with kevino@.
 https://bugs.webkit.org/show_bug.cgi?id=72855
 I hope I had had time to extend the work to WebCore, which was my original
 goal :-/

 I did it through an automation but the tool was so slow and hacky that it
 was not capable for large WebCore codebase.

 Seeing that the number of exported symbol is about 2700, manual work with
 regular expression will also work
 if it is OK to do the work incrementally... and if you are patient enough
 :-)


2700 is a lot of symbols to export! Perhaps we can reduce the number of
exported symbols? For example, we can move more code from WebKit into
WebCore to share more code between ports so that the API surface WebCore
has to expose will be smaller and more well defined.

I also bet there are quite few symbols we export from WebCore that are no
longer used in WebKit.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Mark Rowe

On 2013-01-30, at 17:14, Dirk Pranke dpra...@chromium.org wrote:

 On Wed, Jan 30, 2013 at 4:15 PM, Maciej Stachowiak m...@apple.com wrote:
 
 On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote:
 
 On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote:
 Thanks for sharing this.
 
 On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:
 
 I wish we only had one build system (it were easy to add/remove/move 
 files).
 
 I believe changes like http://trac.webkit.org/changeset/74849 are an
 unhealthy sign for the project.  Adam is not the only person who has chosen
 to empty files instead of removing them.  The pain of updating 8 build
 system is so great, we jump through hoops to avoid it.  Which means it took
 us months to move JavaScriptCore/wtf to WTF, and will take us years to kill
 WebCore/platform.
 
 
 +1
 
 This is a hard problem.  It is a problem worth solving.
 
 Do you have more thoughts on this, particularly since you know quite well
 how both Xcode and gyp work?
 
 I suspect this is one of those things that it would be hard to achieve
 consensus on since there are so many stakeholders.  But it may be fruitful
 to have a what if discussion about what this might look like.
 
 
 I think we can solve this problem if we agree that we want to. I think
 we haven't in the past mostly because we couldn't reach a consensus
 that it was worth solving enough to really try.
 
 I would love to see this fixed and would be glad to work on it. I
 think we should at least pursue this far enough to fully understand
 what our options are and what the costs and tradeoffs might be; does
 anyone disagree, and is anyone else willing to help pitch in?
 
 I think there are several possible ways we could solve this. One would
 be to switch to a common meta-build system. My understanding is that
 Apple's internal production build processes impose certain constraints
 here that I don't fully understand, but I know we've discussed the
 possibility of checking in generated project files as a workaround.
 Maybe there are other options as well to those constraints? I would
 love to discuss this further w/ someone from Apple ...
 
 It's far simplest for us if:
 (a) There is an Xcode project (or a Makefile) that builds the Mac port 
 checked in to source control.
 (b) The generated project invokes only tools that are part of the default 
 Mac OS X install.
 
 It may not be completely impossible to violate these requirements but it 
 will require a lot of bureaucracy.
 
 (Also, just to get this out of the way, I don't think gyp needs to be
 the solution).
 
 Another alternative would be to write a script that did support at
 least the common use cases (add/move/delete files). There have been
 attempts in the past, but they have foundered on at least some
 perceived skepticism over how well this would work w/ XCode. That
 said, I don't think we've really pushed this to see. At some point
 this script might turn into a meta-meta-build system, which might be
 silly but also be the shortest path to the finish line.
 
 I suggest if there is interest in this we can start a new thread to
 discuss further ...
 
 My preference would be to use a common meta-build system with a comfortably 
 human-readable and human-editable syntax, and checked in generated project 
 files for those ports that need them.
 
 I think a key to making this work is to get Chromium and the Apple Mac port 
 onto a common build system, which will probably require both Google and 
 Apple ponying up at least one person to work on this project for a 
 reasonable period of time.
 
 I think the plausible meta-build-systems to use would be CMake and Gyp, but 
 in both cases it may be necessary to modify them to work well for everyone.
 
 
 Premake might also be an option, though I wouldn't necessarily vote
 for it. Gyp's syntax is ... awkward ... but apart from that might just
 work for checking in generated apple mac xcode projects. We should try
 it (shouldn't be too hard, since abarth had it working at one point).

I think Eric and/or Adam had JavaScriptCore building with gyp at one point. I’m 
not sure if they ever got to the other projects.

 I would consider changing or improving gyp's syntax to be on the table
 if it was needed to reach the goal.

For what it’s worth, I also find the gyp syntax to be unpleasant. It feels as 
though it was optimized for being processed by a machine rather than for being 
written and maintained by humans.

 CMake was originally considered a non-starter for chromium since the
 XCode and VS projects it produced didn't look or feel like native
 projects. However, we've since switched to ninja for most things so
 I'm less sure how important this is now. I've never been a huge fan of
 the CMake syntax but I haven't used it enough to really have an
 informed opinion.

Generating well-structured Xcode projects is still something that is important 
for any meta build system that we would consider 

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Adam Barth
On Thu, Jan 31, 2013 at 12:25 AM, Mark Rowe mr...@apple.com wrote:
 On 2013-01-30, at 17:14, Dirk Pranke dpra...@chromium.org wrote:
 On Wed, Jan 30, 2013 at 4:15 PM, Maciej Stachowiak m...@apple.com wrote:
 On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote:
 On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote:
 Thanks for sharing this.

 On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:

 I wish we only had one build system (it were easy to add/remove/move 
 files).

 I believe changes like http://trac.webkit.org/changeset/74849 are an
 unhealthy sign for the project.  Adam is not the only person who has 
 chosen
 to empty files instead of removing them.  The pain of updating 8 build
 system is so great, we jump through hoops to avoid it.  Which means it 
 took
 us months to move JavaScriptCore/wtf to WTF, and will take us years to 
 kill
 WebCore/platform.


 +1

 This is a hard problem.  It is a problem worth solving.

 Do you have more thoughts on this, particularly since you know quite well
 how both Xcode and gyp work?

 I suspect this is one of those things that it would be hard to achieve
 consensus on since there are so many stakeholders.  But it may be fruitful
 to have a what if discussion about what this might look like.


 I think we can solve this problem if we agree that we want to. I think
 we haven't in the past mostly because we couldn't reach a consensus
 that it was worth solving enough to really try.

 I would love to see this fixed and would be glad to work on it. I
 think we should at least pursue this far enough to fully understand
 what our options are and what the costs and tradeoffs might be; does
 anyone disagree, and is anyone else willing to help pitch in?

 I think there are several possible ways we could solve this. One would
 be to switch to a common meta-build system. My understanding is that
 Apple's internal production build processes impose certain constraints
 here that I don't fully understand, but I know we've discussed the
 possibility of checking in generated project files as a workaround.
 Maybe there are other options as well to those constraints? I would
 love to discuss this further w/ someone from Apple ...

 It's far simplest for us if:
 (a) There is an Xcode project (or a Makefile) that builds the Mac port 
 checked in to source control.
 (b) The generated project invokes only tools that are part of the default 
 Mac OS X install.

 It may not be completely impossible to violate these requirements but it 
 will require a lot of bureaucracy.

 (Also, just to get this out of the way, I don't think gyp needs to be
 the solution).

 Another alternative would be to write a script that did support at
 least the common use cases (add/move/delete files). There have been
 attempts in the past, but they have foundered on at least some
 perceived skepticism over how well this would work w/ XCode. That
 said, I don't think we've really pushed this to see. At some point
 this script might turn into a meta-meta-build system, which might be
 silly but also be the shortest path to the finish line.

 I suggest if there is interest in this we can start a new thread to
 discuss further ...

 My preference would be to use a common meta-build system with a comfortably 
 human-readable and human-editable syntax, and checked in generated project 
 files for those ports that need them.

 I think a key to making this work is to get Chromium and the Apple Mac port 
 onto a common build system, which will probably require both Google and 
 Apple ponying up at least one person to work on this project for a 
 reasonable period of time.

 I think the plausible meta-build-systems to use would be CMake and Gyp, but 
 in both cases it may be necessary to modify them to work well for everyone.


 Premake might also be an option, though I wouldn't necessarily vote
 for it. Gyp's syntax is ... awkward ... but apart from that might just
 work for checking in generated apple mac xcode projects. We should try
 it (shouldn't be too hard, since abarth had it working at one point).

 I think Eric and/or Adam had JavaScriptCore building with gyp at one point. 
 I’m not sure if they ever got to the other projects.

We had JavaScriptCore and WebCore working.  (We also had
JavaScriptGlue, but that doesn't exist anymore.)  I don't remember if
we had WebKit/mac working.  (WebKit2 didn't exist at the time.)

 I would consider changing or improving gyp's syntax to be on the table
 if it was needed to reach the goal.

 For what it’s worth, I also find the gyp syntax to be unpleasant. It feels as 
 though it was optimized for being processed by a machine rather than for 
 being written and maintained by humans.

Unlike xcodeproj files.  :)

 CMake was originally considered a non-starter for chromium since the
 XCode and VS projects it produced didn't look or feel like native
 projects. However, we've since switched to ninja for most things so
 I'm less sure how 

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Patrick Gansterer
Hi,

Am 31.01.2013 um 09:25 schrieb Mark Rowe:
 CMake was originally considered a non-starter for chromium since the
 XCode and VS projects it produced didn't look or feel like native
 projects. However, we've since switched to ninja for most things so
 I'm less sure how important this is now. I've never been a huge fan of
 the CMake syntax but I haven't used it enough to really have an
 informed opinion.
 
 Generating well-structured Xcode projects is still something that is 
 important for any meta build system that we would consider adopting for the 
 Mac. It would be substantially more challenging for us to support an 
 alternative system for building our production builds. If there are 
 substantial advantages to using ninja for engineering builds then we may wish 
 to support both to get the best behavior in each environment.
 
 The non-natively structured Xcode projects is one thing that turned me off 
 CMake when I looked at it in the past. I’m not sure if this has improved 
 since then. If not, then I don’t think CMake is worth spending much time on.

If you want to commit the generated projects CMake isn't an option anyway, 
since it uses absolute paths and also requires a cmake binary on the machine 
used for compiling (to support all CMake features across all generators). This 
tight integration is usually a big win, since the CMakeLists.txt files are part 
of the build system they can be changed directly in the IDE and update the 
project without invoking external tools.

Only for my personal interest: What do you mean exactly with non-natively 
structured Xcode projects? CMake aims to support a native IDE feel as far as 
possible. Would be great if you explain that to me (off-list) to get CMake 
improved for XCode?

 Regarding (b) The generated project invokes only tools that are part
 of the default Mac OS X install: invoking tools that are checked into
 the WK repo is also possible, right, since we invoke scripts now? So,
 hypothetically, could we check in a copy of the ninja binary and build
 with that?
 
 Checking in binaries isn’t an option for us, and isn’t a particularly 
 scalable approach anyway given the number of platforms that WebKit can build 
 on. If we require an external tool as a dependency to build WebKit from 
 source then we’d need to check in the source for the tool and build it prior 
 to building WebKit proper. This obviously introduces more complexity so it 
 would be preferable to keep the dependencies to a minimum.

Maybe you can check in the ninja source and compile it during build. It only 
requires python (and hopefully installed build tools) to get built.

-- Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Mark Rowe

On 2013-01-31, at 00:48, Adam Barth aba...@webkit.org wrote:

 I would consider changing or improving gyp's syntax to be on the table
 if it was needed to reach the goal.
 
 For what it’s worth, I also find the gyp syntax to be unpleasant. It feels 
 as though it was optimized for being processed by a machine rather than for 
 being written and maintained by humans.
 
 Unlike xcodeproj files.  :)

Don’t get me wrong, Xcode projects suck for hand-editing too. However, they’re 
not intended to be edited by hand. Gyp files are, and so the expected level of 
human readability is much higher.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Jochen Eisinger
On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe mr...@apple.com wrote:


 On 2013-01-31, at 00:48, Adam Barth aba...@webkit.org wrote:

  I would consider changing or improving gyp's syntax to be on the table
  if it was needed to reach the goal.
 
  For what it’s worth, I also find the gyp syntax to be unpleasant. It
 feels as though it was optimized for being processed by a machine rather
 than for being written and maintained by humans.
 
  Unlike xcodeproj files.  :)

 Don’t get me wrong, Xcode projects suck for hand-editing too. However,
 they’re not intended to be edited by hand. Gyp files are, and so the
 expected level of human readability is much higher.


Many of us are actually editing the Xcode projects by hand, either because
they don't have Xcode or don't know how to use it. (Yes, that includes
coming up with a bunch of new UUIDs by hand)

best
-jochen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Hajime Morrita
On Thu, Jan 31, 2013 at 5:49 PM, Patrick Gansterer par...@paroga.comwrote:

 Hi,

 Am 31.01.2013 um 09:25 schrieb Mark Rowe:
  CMake was originally considered a non-starter for chromium since the
  XCode and VS projects it produced didn't look or feel like native
  projects. However, we've since switched to ninja for most things so
  I'm less sure how important this is now. I've never been a huge fan of
  the CMake syntax but I haven't used it enough to really have an
  informed opinion.
 
  Generating well-structured Xcode projects is still something that is
 important for any meta build system that we would consider adopting for the
 Mac. It would be substantially more challenging for us to support an
 alternative system for building our production builds. If there are
 substantial advantages to using ninja for engineering builds then we may
 wish to support both to get the best behavior in each environment.
 
  The non-natively structured Xcode projects is one thing that turned me
 off CMake when I looked at it in the past. I’m not sure if this has
 improved since then. If not, then I don’t think CMake is worth spending
 much time on.

 If you want to commit the generated projects CMake isn't an option anyway,
 since it uses absolute paths and also requires a cmake binary on the
 machine used for compiling (to support all CMake features across all
 generators). This tight integration is usually a big win, since the
 CMakeLists.txt files are part of the build system they can be changed
 directly in the IDE and update the project without invoking external tools.

 Only for my personal interest: What do you mean exactly with non-natively
 structured Xcode projects? CMake aims to support a native IDE feel as far
 as possible. Would be great if you explain that to me (off-list) to get
 CMake improved for XCode?

  Regarding (b) The generated project invokes only tools that are part
  of the default Mac OS X install: invoking tools that are checked into
  the WK repo is also possible, right, since we invoke scripts now? So,
  hypothetically, could we check in a copy of the ninja binary and build
  with that?
 

 Checking in binaries isn’t an option for us, and isn’t a particularly
 scalable approach anyway given the number of platforms that WebKit can
 build on. If we require an external tool as a dependency to build WebKit
 from source then we’d need to check in the source for the tool and build it
 prior to building WebKit proper. This obviously introduces more complexity
 so it would be preferable to keep the dependencies to a minimum.

 Maybe you can check in the ninja source and compile it during build. It
 only requires python (and hopefully installed build tools) to get built.


In my understanding, it doesn't matter whether Apple Mac port supports
ninja or not. We could use GNU make if some meta-build system is adopted
because Mac OS has it installed. The problem here is that the neither CMake
and GYP isn't easy to adopt for reasons discussed in this thread.

My personal feeling is that we could build a simple meta build system which
specifically targetsMac WebKit and XCode.

It could be just a little more than a templating system which generates the
list of files plus their UUIDs. The tool doesn't need to be so general like
CMake/GYP. Many tricky configuration things could be in the hard-coded
boilerplate. It could just focus on generating file list and UUIDs. It's
something like project.pbxproj.in and its preprocessor.

It won't be a direct step toward the unified build system. But we'll figure
out the next step once the build is represented by a simple plain text.

--
morrita


 -- Patrick
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Hajime Morrita
In my understanding, it doesn't matter whether Apple Mac port supports
ninja or not. We could use GNU make if some meta-build system is adopted
because Mac OS has it installed. The problem here is that the neither CMake
and GYP isn't easy to adopt for reasons discussed in this thread.

My personal feeling is that we could build a simple meta build system which
specifically targetsMac WebKit and XCode.

It could be just a little more than a templating system which generates the
list of files plus their UUIDs. The tool doesn't need to be so general like
CMake/GYP. Many tricky configuration things could be in the hard-coded
boilerplate. It could just focus on generating file list and UUIDs. It's
something like project.pbxproj.in and its preprocessor.

It won't be a direct step toward the unified build system. But we'll figure
out the next step once the build is represented by a simple plain text.

--
morrita


On Thu, Jan 31, 2013 at 5:49 PM, Patrick Gansterer par...@paroga.comwrote:

 Hi,

 Am 31.01.2013 um 09:25 schrieb Mark Rowe:
  CMake was originally considered a non-starter for chromium since the
  XCode and VS projects it produced didn't look or feel like native
  projects. However, we've since switched to ninja for most things so
  I'm less sure how important this is now. I've never been a huge fan of
  the CMake syntax but I haven't used it enough to really have an
  informed opinion.
 
  Generating well-structured Xcode projects is still something that is
 important for any meta build system that we would consider adopting for the
 Mac. It would be substantially more challenging for us to support an
 alternative system for building our production builds. If there are
 substantial advantages to using ninja for engineering builds then we may
 wish to support both to get the best behavior in each environment.
 
  The non-natively structured Xcode projects is one thing that turned me
 off CMake when I looked at it in the past. I’m not sure if this has
 improved since then. If not, then I don’t think CMake is worth spending
 much time on.

 If you want to commit the generated projects CMake isn't an option anyway,
 since it uses absolute paths and also requires a cmake binary on the
 machine used for compiling (to support all CMake features across all
 generators). This tight integration is usually a big win, since the
 CMakeLists.txt files are part of the build system they can be changed
 directly in the IDE and update the project without invoking external tools.

 Only for my personal interest: What do you mean exactly with non-natively
 structured Xcode projects? CMake aims to support a native IDE feel as far
 as possible. Would be great if you explain that to me (off-list) to get
 CMake improved for XCode?

  Regarding (b) The generated project invokes only tools that are part
  of the default Mac OS X install: invoking tools that are checked into
  the WK repo is also possible, right, since we invoke scripts now? So,
  hypothetically, could we check in a copy of the ninja binary and build
  with that?
 
  Checking in binaries isn’t an option for us, and isn’t a particularly
 scalable approach anyway given the number of platforms that WebKit can
 build on. If we require an external tool as a dependency to build WebKit
 from source then we’d need to check in the source for the tool and build it
 prior to building WebKit proper. This obviously introduces more complexity
 so it would be preferable to keep the dependencies to a minimum.

 Maybe you can check in the ninja source and compile it during build. It
 only requires python (and hopefully installed build tools) to get built.

 -- Patrick
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Mark Rowe

On 2013-01-31, at 00:59, Jochen Eisinger joc...@chromium.org wrote:

 
 
 On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe mr...@apple.com wrote:
 
 On 2013-01-31, at 00:48, Adam Barth aba...@webkit.org wrote:
 
  I would consider changing or improving gyp's syntax to be on the table
  if it was needed to reach the goal.
 
  For what it’s worth, I also find the gyp syntax to be unpleasant. It feels 
  as though it was optimized for being processed by a machine rather than 
  for being written and maintained by humans.
 
  Unlike xcodeproj files.  :)
 
 Don’t get me wrong, Xcode projects suck for hand-editing too. However, 
 they’re not intended to be edited by hand. Gyp files are, and so the expected 
 level of human readability is much higher.
 
 Many of us are actually editing the Xcode projects by hand, either because 
 they don't have Xcode or don't know how to use it. (Yes, that includes coming 
 up with a bunch of new UUIDs by hand)


I wasn’t trying to suggest that current situation is a good one, only that if 
it would be easier to get momentum on switching to something like gyp if the 
replacement’s syntax was friendlier. Particularly when the people that need to 
be convinced to switch, and who’ll have to adapt their workflow, are those that 
are editing the project files in a nice GUI.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Mark Rowe

On 2013-01-31, at 01:07, Hajime Morrita morr...@chromium.org wrote:

 In my understanding, it doesn't matter whether Apple Mac port supports ninja 
 or not. We could use GNU make if some meta-build system is adopted because 
 Mac OS has it installed. The problem here is that the neither CMake and GYP 
 isn't easy to adopt for reasons discussed in this thread.

As I mentioned in an earlier email, we need to keep the Mac port building via 
Xcode for our production builds.

 My personal feeling is that we could build a simple meta build system which 
 specifically targetsMac WebKit and XCode.
 
 It could be just a little more than a templating system which generates the 
 list of files plus their UUIDs. The tool doesn't need to be so general like 
 CMake/GYP. Many tricky configuration things could be in the hard-coded 
 boilerplate. It could just focus on generating file list and UUIDs. It's 
 something like project.pbxproj.in and its preprocessor.
 
 It won't be a direct step toward the unified build system. But we'll figure 
 out the next step once the build is represented by a simple plain text.

I’ve experimented with this in the past and you’re right that it shouldn’t be 
particularly difficult to do. However, I suspect that the task would be similar 
in scope to defining an improved syntax for gyp. And if the syntax is the 
primary sticking point with gyp then it’d seem preferable to tackle initially.

I should also clarify that I don’t think gyp’s current syntax is a showstoppper 
for adoption. I’d just like to see it improved.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Jochen Eisinger
On Thu, Jan 31, 2013 at 10:12 AM, Mark Rowe mr...@apple.com wrote:


 On 2013-01-31, at 00:59, Jochen Eisinger joc...@chromium.org wrote:



 On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe mr...@apple.com wrote:


 On 2013-01-31, at 00:48, Adam Barth aba...@webkit.org wrote:

  I would consider changing or improving gyp's syntax to be on the table
  if it was needed to reach the goal.
 
  For what it’s worth, I also find the gyp syntax to be unpleasant. It
 feels as though it was optimized for being processed by a machine rather
 than for being written and maintained by humans.
 
  Unlike xcodeproj files.  :)

 Don’t get me wrong, Xcode projects suck for hand-editing too. However,
 they’re not intended to be edited by hand. Gyp files are, and so the
 expected level of human readability is much higher.


 Many of us are actually editing the Xcode projects by hand, either because
 they don't have Xcode or don't know how to use it. (Yes, that includes
 coming up with a bunch of new UUIDs by hand)


 I wasn’t trying to suggest that current situation is a good one, only that
 if it would be easier to get momentum on switching to something like gyp if
 the replacement’s syntax was friendlier. Particularly when the people that
 need to be convinced to switch, and who’ll have to adapt their workflow,
 are those that are editing the project files in a nice GUI.


Agreed.

Another option is to add a webkit-patch command for modifying the build
files. That way, the syntax doesn't need to be overly human friendly. There
was also some attempt to write a tool to add files automatically:
https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a
tool becomes easier if it would only modify one source of truth and
generates all other artifacts such as Xcode projects from it.

best
-jochen




 - Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Ryosuke Niwa
On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.orgwrote:

 Another option is to add a webkit-patch command for modifying the build
 files. That way, the syntax doesn't need to be overly human friendly. There
 was also some attempt to write a tool to add files automatically:
 https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a
 tool becomes easier if it would only modify one source of truth and
 generates all other artifacts such as Xcode projects from it.


I don't want build file's syntax to be so human unfriendly that I need a
tool for it.

Often times, these syntax problems can be improved dramatically by simple
changes. e.g. we had a similar discussion about TestExpectation syntax, and
I'm much happier with the new syntax even though the new syntax is
functionally equivalent to the old one, and two syntaxes are very similar.

On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:

 I’ve experimented with this in the past and you’re right that it shouldn’t
 be particularly difficult to do. However, I suspect that the task would be
 similar in scope to defining an improved syntax for gyp. And if the syntax
 is the primary sticking point with gyp then it’d seem preferable to tackle
 initially.


Yeah. In fact, we can just come up with whatever syntax we like and convert
it to the existing gyp format if the syntax was the biggest issue.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Patrick Gansterer
Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:

 On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org wrote:
 Another option is to add a webkit-patch command for modifying the build 
 files. That way, the syntax doesn't need to be overly human friendly. There 
 was also some attempt to write a tool to add files automatically: 
 https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a 
 tool becomes easier if it would only modify one source of truth and generates 
 all other artifacts such as Xcode projects from it.
 
 I don't want build file's syntax to be so human unfriendly that I need a tool 
 for it.
 
 Often times, these syntax problems can be improved dramatically by simple 
 changes. e.g. we had a similar discussion about TestExpectation syntax, and 
 I'm much happier with the new syntax even though the new syntax is 
 functionally equivalent to the old one, and two syntaxes are very similar.
 
 On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:
 I’ve experimented with this in the past and you’re right that it shouldn’t be 
 particularly difficult to do. However, I suspect that the task would be 
 similar in scope to defining an improved syntax for gyp. And if the syntax is 
 the primary sticking point with gyp then it’d seem preferable to tackle 
 initially.
 
 Yeah. In fact, we can just come up with whatever syntax we like and convert 
 it to the existing gyp format if the syntax was the biggest issue.

Do we want to define the whole build system (including information how to 
invoke the generators) with the new system, or is a simple list for the input 
files sufficient? IMHO adding a new generator build step happens very rarely. 
So maybe we can spit the input file list (mainly *.cpp and *.idl) into new 
files.
Then GYP and CMake can read them and generate the build system out of them 
directly (like they to already today) instead of listing the files in the 
*.gpyi and *.cmake. This might work for other systems like qmake too.
For XCode we can maybe have a template XCode project and generate the work 
XCode project with a script. This script then only need to fill in the files 
from the input file list into the template XCode project.
Defining the feature flags can be done like Maciej suggested with Port.h 
files.

-- Patrick___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Alexis Menard
On Thu, Jan 31, 2013 at 6:56 AM, Patrick Gansterer par...@paroga.com wrote:
 Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:

 On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org
 wrote:

 Another option is to add a webkit-patch command for modifying the build
 files. That way, the syntax doesn't need to be overly human friendly. There
 was also some attempt to write a tool to add files automatically:
 https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a
 tool becomes easier if it would only modify one source of truth and
 generates all other artifacts such as Xcode projects from it.


 I don't want build file's syntax to be so human unfriendly that I need a
 tool for it.

 Often times, these syntax problems can be improved dramatically by simple
 changes. e.g. we had a similar discussion about TestExpectation syntax, and
 I'm much happier with the new syntax even though the new syntax is
 functionally equivalent to the old one, and two syntaxes are very similar.

 On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:

 I’ve experimented with this in the past and you’re right that it shouldn’t
 be particularly difficult to do. However, I suspect that the task would be
 similar in scope to defining an improved syntax for gyp. And if the syntax
 is the primary sticking point with gyp then it’d seem preferable to tackle
 initially.


 Yeah. In fact, we can just come up with whatever syntax we like and convert
 it to the existing gyp format if the syntax was the biggest issue.


 Do we want to define the whole build system (including information how to
 invoke the generators) with the new system, or is a simple list for the
 input files sufficient? IMHO adding a new generator build step happens very
 rarely. So maybe we can spit the input file list (mainly *.cpp and *.idl)
 into new files.
 Then GYP and CMake can read them and generate the build system out of them
 directly (like they to already today) instead of listing the files in the
 *.gpyi and *.cmake. This might work for other systems like qmake too.
 For XCode we can maybe have a template XCode project and generate the
 work XCode project with a script. This script then only need to fill in
 the files from the input file list into the template XCode project.
 Defining the feature flags can be done like Maciej suggested with Port.h
 files.

My 2 cents.

One advantage CMake has over other proposals is that it's already
working for 2 ports (and potentially 4). It is an open source project
so we could potentially contribute to it to add or fix what is needed.
One other good point for CMake is that it's widely used in the
industry and it is backed by a company. When KDE switched over CMake
the guys behind CMake were very very responsive, I believe they will
be too if we plan to switch to CMake. The more famous projects they
have running CMake, the better it is for them. So if we need to
improve the Xcode support then I bet we can count on them. CMake has
also some support in various IDE, and if not then the native solution
is a fallback.

Sure the syntax is maybe not the best but it no worst than Gyp, Xcode,
Makefiles, qmake or some perl script. We already live with all these
syntax and people are also used to edit the CMake related project.

Perfect build system do not exist it's a fact.

On the other hand I don't want to loose the native support like Xcode.
I don't know if many are using it but I find incredibly convenient to
open the Xcode workspace of WebKit, setup the two little things
instructed in the wiki and press cmd+b and it just works, it builds,
it integrate with Xcode (so you get the neat features of pretty output
compiles errors with jumping, ...) and I press cmd+r and it launch
MiniBrowser or something else to debug from within the IDE. This is
what makes the Mac port a very great port to work on.


 -- Patrick

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev




-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Jochen Eisinger
On Thu, Jan 31, 2013 at 10:37 AM, Ryosuke Niwa rn...@webkit.org wrote:

 On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.orgwrote:

 Another option is to add a webkit-patch command for modifying the build
 files. That way, the syntax doesn't need to be overly human friendly. There
 was also some attempt to write a tool to add files automatically:
 https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such
 a tool becomes easier if it would only modify one source of truth and
 generates all other artifacts such as Xcode projects from it.


 I don't want build file's syntax to be so human unfriendly that I need a
 tool for it.

 Often times, these syntax problems can be improved dramatically by simple
 changes. e.g. we had a similar discussion about TestExpectation syntax, and
 I'm much happier with the new syntax even though the new syntax is
 functionally equivalent to the old one, and two syntaxes are very similar.


I totally agree. I guess I just failed at finding the right words.

-jochen



 On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:

 I’ve experimented with this in the past and you’re right that it
 shouldn’t be particularly difficult to do. However, I suspect that the task
 would be similar in scope to defining an improved syntax for gyp. And if
 the syntax is the primary sticking point with gyp then it’d seem preferable
 to tackle initially.


 Yeah. In fact, we can just come up with whatever syntax we like and
 convert it to the existing gyp format if the syntax was the biggest issue.

 - R. Niwa


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKit Wishes

2013-01-31 Thread Alexis Menard
On Wed, Jan 30, 2013 at 6:28 PM, Eric Seidel e...@webkit.org wrote:
 I wish we only had one build system (it were easy to add/remove/move files).

 I believe changes like http://trac.webkit.org/changeset/74849 are an
 unhealthy sign for the project.  Adam is not the only person who has chosen
 to empty files instead of removing them.  The pain of updating 8 build
 system is so great, we jump through hoops to avoid it.  Which means it took
 us months to move JavaScriptCore/wtf to WTF, and will take us years to kill
 WebCore/platform.


 I wish I felt like reviewers understood/trusted each other more.

 I’ve worked at both Apple and Google.  The WebKit community is full of
 brilliant engineers.  Yet I frequently feel a lack of trust in my (or
 others) judgement, or witness hot-headed remarks on bugs, lists or IRC.  I
 don’t think it’s that people don’t trust me after nearly 8 years (!?) on
 this project, but rather that we forget, or fail to communicate trust among
 ourselves.  Social problems are perhaps harder to solve for us technical
 types, but I worry that for many of us it’s just become “us” and “them” and
 we’ve stopped trying.


 I wish it were easy to work on feature branches.

 We have no good solution for features.  For one-patch features, you do them
 on your own.  For larger, you maybe use github or most likely you just land
 on trunk behind a #define.  None of these have worked well.  Some of this is
 the limits of SVN, but it should be trivial for someone to work on a new
 feature a long time, w/o endangering trunk or having massive merge pain
 every day.  Other projects can do this.  So should we.  This is both
 impeding progress, and destabilizing trunk.


 I wish we didn’t have to worry about platforms we couldn’t test.

 It can’t be the job of the core maintainers to care about all the peripheral
 ports which contribute very little core code. Our code needs to be
 structured in such a manner that its easy for the core to march forward,
 while letting the ports catch up as they need to asynchronously.  Platform
 support code shouldn’t even need to be in webkit.org!  Porting webkit.org’s
 platform abstractions should be trivial, but core developers (which probably
 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to
 worry about keeping all ports working.

Sure. I'm wondering how you would define a peripheral port? Anything
not Apple or Google?

Many little ports are very active every day, sure some of them does
not contribute as much as they should on common parts but some
companies behind these are just limited on resources. They are not
Google or Apple with an army of engineers who have time to take any
spec of W3C and implements it.

In WebCore the contribution is pain mostly because the buildsystem.
For the rest if EWS goes red, in many cases it's a real bug, a real
problem.

Coming from a so called peripheral port I find very frustrating and
demotivating that our contributions are devalorized the way they are
or our reviews discredited. Many of us contributes important feature
and improvements to WebCore and sure not as visible as Google or Apple
in terms of log but still crucial or important.

I believe you and many people are not aware what little ports
contribute because we don't work on high visibility feature such as
Regions, Grid, FooBar W3C API. We do improve W3C compliance (CSS, XHR,
media queries, viewport interactions, @viewport rule, various work on
tests infrastructure, WebGL fixes) and I'm talking only of the people
in my company and I'm probably forgetting some work. The number of
contributions per day makes hard for me to see what others than Google
or Apple are doing.

I tend to agree that some are not playing the game but for the ones
who try their best it's sad to be rejected like that.



 I wish that the tree always built and tested cleanly.

 Other (much larger) projects than WebKit accomplish this.  Yet somehow
 Google pays 2 full-time engineers to watch our bots and yet we fail.  I know
 other companies do similar.  Automated rollouts is one solution.
 Branched-based development, or trybots are others.  But at the size and
 scale we’re at now, every minute of a broken tree, is 100x or more minutes
 of potentially lost developer productivity.


 I wish I felt like I could follow what was going on (and trust WebKit to
 guard the web, instead of depending on Apple or Google).

 We’re the leading browser engine, with hundreds of committers, any of whom
 can add an API to 50% of internet browsers with a single commit.  I wish we
 had a public process for feature/web-api review.  I wish I felt like both
 major companies were willing participants in such.  (Google has an internal
 process, but it sees limited use, in part because it’s powerless -- a ‘yes’
 from our process is not a ‘yes’ from WebKit.)  I want to feel like I can
 better observe and participate in the development of our web-api (and trust
 that it’s being done well!) without 

Re: [webkit-dev] WebKit Wishes

2013-01-31 Thread Ryosuke Niwa
On Thu, Jan 31, 2013 at 4:16 AM, Alexis Menard ale...@webkit.org wrote:

 On Wed, Jan 30, 2013 at 6:28 PM, Eric Seidel e...@webkit.org wrote:
 
  I wish we didn’t have to worry about platforms we couldn’t test.
 
  It can’t be the job of the core maintainers to care about all the
 peripheral
  ports which contribute very little core code. Our code needs to be
  structured in such a manner that its easy for the core to march forward,
  while letting the ports catch up as they need to asynchronously.
  Platform
  support code shouldn’t even need to be in webkit.org!  Porting
 webkit.org’s
  platform abstractions should be trivial, but core developers (which
 probably
  90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to
  worry about keeping all ports working.

 Sure. I'm wondering how you would define a peripheral port? Anything
 not Apple or Google?

 Many little ports are very active every day, sure some of them does
 not contribute as much as they should on common parts but some
 companies behind these are just limited on resources. They are not
 Google or Apple with an army of engineers who have time to take any
 spec of W3C and implements it.

 In WebCore the contribution is pain mostly because the buildsystem.
 For the rest if EWS goes red, in many cases it's a real bug, a real
 problem.

 Coming from a so called peripheral port I find very frustrating and
 demotivating that our contributions are devalorized the way they are
 or our reviews discredited. Many of us contributes important feature
 and improvements to WebCore and sure not as visible as Google or Apple
 in terms of log but still crucial or important.

 I believe you and many people are not aware what little ports
 contribute because we don't work on high visibility feature such as
 Regions, Grid, FooBar W3C API. We do improve W3C compliance (CSS, XHR,
 media queries, viewport interactions, @viewport rule, various work on
 tests infrastructure, WebGL fixes) and I'm talking only of the people
 in my company and I'm probably forgetting some work. The number of
 contributions per day makes hard for me to see what others than Google
 or Apple are doing.

 I tend to agree that some are not playing the game but for the ones
 who try their best it's sad to be rejected like that.


I don't think Eric's intended to marginalize the importance or the value of
contributions non-Apple/Google ports have been making.

I think he's merely trying to point out that the ratio of the contribution
each port makes to the cost the same port imposes, i.e. contribution/cost,
is positively correlated with the size of a port. Larger the port, it can
contribute more to the core code without imposing proportionally larger
cost. Smaller the port, it needs to spend more time fixing and implementing
its own port-specific code. In some cases, they may not have resources or
expertises to help other contributors trying to make a large refactoring.

While contributors from a smal port may feel as though their work
is marginalized and other ports' contributors ruthlessly break their port,
contributors from a large port often feel that they're being taxed by small
ports; having to maintain other ports without getting much benefit out of
them.

And I suggest we *find a technical solution *to this problem instead of
talking about which philosophy or policy is right.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Maciej Stachowiak

On Jan 31, 2013, at 12:49 AM, Patrick Gansterer par...@paroga.com wrote:

 Hi,
 
 Am 31.01.2013 um 09:25 schrieb Mark Rowe:
 
 Regarding (b) The generated project invokes only tools that are part
 of the default Mac OS X install: invoking tools that are checked into
 the WK repo is also possible, right, since we invoke scripts now? So,
 hypothetically, could we check in a copy of the ninja binary and build
 with that?
 
 Checking in binaries isn’t an option for us, and isn’t a particularly 
 scalable approach anyway given the number of platforms that WebKit can build 
 on. If we require an external tool as a dependency to build WebKit from 
 source then we’d need to check in the source for the tool and build it prior 
 to building WebKit proper. This obviously introduces more complexity so it 
 would be preferable to keep the dependencies to a minimum.
 
 Maybe you can check in the ninja source and compile it during build. It only 
 requires python (and hopefully installed build tools) to get built.

Depending on how this is done it might be possible, but as I understand it gyp 
can build ok without ninja, so it doesn't seem strictly necessary.

Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Maciej Stachowiak

On Jan 31, 2013, at 1:56 AM, Patrick Gansterer par...@paroga.com wrote:

 Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
 
 On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org wrote:
 Another option is to add a webkit-patch command for modifying the build 
 files. That way, the syntax doesn't need to be overly human friendly. There 
 was also some attempt to write a tool to add files automatically: 
 https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a 
 tool becomes easier if it would only modify one source of truth and 
 generates all other artifacts such as Xcode projects from it.
 
 I don't want build file's syntax to be so human unfriendly that I need a 
 tool for it.
 
 Often times, these syntax problems can be improved dramatically by simple 
 changes. e.g. we had a similar discussion about TestExpectation syntax, and 
 I'm much happier with the new syntax even though the new syntax is 
 functionally equivalent to the old one, and two syntaxes are very similar.
 
 On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:
 I’ve experimented with this in the past and you’re right that it shouldn’t 
 be particularly difficult to do. However, I suspect that the task would be 
 similar in scope to defining an improved syntax for gyp. And if the syntax 
 is the primary sticking point with gyp then it’d seem preferable to tackle 
 initially.
 
 Yeah. In fact, we can just come up with whatever syntax we like and convert 
 it to the existing gyp format if the syntax was the biggest issue.
 
 Do we want to define the whole build system (including information how to 
 invoke the generators) with the new system, or is a simple list for the 
 input files sufficient? IMHO adding a new generator build step happens very 
 rarely. So maybe we can spit the input file list (mainly *.cpp and *.idl) 
 into new files.
 Then GYP and CMake can read them and generate the build system out of them 
 directly (like they to already today) instead of listing the files in the 
 *.gpyi and *.cmake. This might work for other systems like qmake too.
 For XCode we can maybe have a template XCode project and generate the work 
 XCode project with a script. This script then only need to fill in the files 
 from the input file list into the template XCode project.
 Defining the feature flags can be done like Maciej suggested with Port.h 
 files.

I think it would be better to adapt an existing meta build system to our needs 
than to make one from scratch, unless we find that completely impractical.

In particular, gyp and cmake both know how to handle generated sources, and 
while it may not be super common to make a new type of generated source, it's 
bad for hackability of the project of doing so is super hard. We get a lot of 
hackability benefits from using various kinds of generated sources, many first 
introduced in the days when we had a lot fewer build systems. So in my mind, 
they are already ahead of a hypothetical simple system.

Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Patrick Gansterer

Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:

 
 On Jan 31, 2013, at 1:56 AM, Patrick Gansterer par...@paroga.com wrote:
 
 Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
 
 On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org 
 wrote:
 Another option is to add a webkit-patch command for modifying the build 
 files. That way, the syntax doesn't need to be overly human friendly. There 
 was also some attempt to write a tool to add files automatically: 
 https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a 
 tool becomes easier if it would only modify one source of truth and 
 generates all other artifacts such as Xcode projects from it.
 
 I don't want build file's syntax to be so human unfriendly that I need a 
 tool for it.
 
 Often times, these syntax problems can be improved dramatically by simple 
 changes. e.g. we had a similar discussion about TestExpectation syntax, and 
 I'm much happier with the new syntax even though the new syntax is 
 functionally equivalent to the old one, and two syntaxes are very similar.
 
 On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:
 I’ve experimented with this in the past and you’re right that it shouldn’t 
 be particularly difficult to do. However, I suspect that the task would be 
 similar in scope to defining an improved syntax for gyp. And if the syntax 
 is the primary sticking point with gyp then it’d seem preferable to tackle 
 initially.
 
 Yeah. In fact, we can just come up with whatever syntax we like and convert 
 it to the existing gyp format if the syntax was the biggest issue.
 
 Do we want to define the whole build system (including information how to 
 invoke the generators) with the new system, or is a simple list for the 
 input files sufficient? IMHO adding a new generator build step happens very 
 rarely. So maybe we can spit the input file list (mainly *.cpp and *.idl) 
 into new files.
 Then GYP and CMake can read them and generate the build system out of them 
 directly (like they to already today) instead of listing the files in the 
 *.gpyi and *.cmake. This might work for other systems like qmake too.
 For XCode we can maybe have a template XCode project and generate the 
 work XCode project with a script. This script then only need to fill in 
 the files from the input file list into the template XCode project.
 Defining the feature flags can be done like Maciej suggested with Port.h 
 files.
 
 I think it would be better to adapt an existing meta build system to our 
 needs than to make one from scratch, unless we find that completely 
 impractical.
 
 In particular, gyp and cmake both know how to handle generated sources, and 
 while it may not be super common to make a new type of generated source, it's 
 bad for hackability of the project of doing so is super hard. We get a lot of 
 hackability benefits from using various kinds of generated sources, many 
 first introduced in the days when we had a lot fewer build systems. So in my 
 mind, they are already ahead of a hypothetical simple system.


Do you want to kick the requirements of the smaller ports from trunk or do you 
think that e.g. a qmake generate for GYP makes sense?
AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system, where 
CMake/GYP is not an option.

I completely agree that creating a new meta meta build system isn't a good 
idea, but sharing the common parts (which reduce the daily productivity) might 
be a step in the right direction. Using simple text files which contain the 
list of files (like the gpyi files already do today) isn't a new build system. 
It only offers the existing meta build systems (CMake, GYP, autotools, qmake) 
to use a common base.

The remaining build systems can be ported to one of these systems or be adopted 
to use this file lists too.

-- Patrick___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Media Server Development

2013-01-31 Thread Kiran K
HI All,

I am working on QtWebKit  on Media Server development. Basic Idea is to run
Gstreamer in seperate process which acts like a Media server. The calls
from WebKit in MediaPlayerPrivateGStreamer.cpp are routed to Media Server
via DBUS. Media Server implements the methods in
MediaPlayerPrivateGStreamer class. I am basically doing this to have
control over the resources like maximum playback instances, hw codec
control etc. I am able to do achieve playback to some extent. I am facing
some problems  (race conditions) especially when deleting playback
instance. From the logs i concluded that when duration() function is made
and is waiting for response from server, ~MediaPlayerPrivateGStreamer
destructor is getting called. (some times vice versa too). I am suspecting
that the MediaPlayer object is being shared between two threads (or across
timers). Can anybody give me some pointers about HTMLMediaElement  and the
timers involved? Any help is appreciated.

Thanks,
Arun
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Ryosuke Niwa
On Thu, Jan 31, 2013 at 9:43 AM, Alexey Proskuryakov a...@apple.com wrote:


 31.01.2013, в 0:17, Ryosuke Niwa rn...@webkit.org написал(а):

  I did it for WTF and JSC with kevino@.
 https://bugs.webkit.org/show_bug.cgi?id=72855
 I hope I had had time to extend the work to WebCore, which was my
 original goal :-/

 I did it through an automation but the tool was so slow and hacky that it
 was not capable for large WebCore codebase.

 Seeing that the number of exported symbol is about 2700, manual work with
 regular expression will also work
 if it is OK to do the work incrementally... and if you are patient enough
 :-)


 2700 is a lot of symbols to export! Perhaps we can reduce the number of
 exported symbols? For example, we can move more code from WebKit into
 WebCore to share more code between ports so that the API surface WebCore
 has to expose will be smaller and more well defined.


 One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
 the number of exports for each port, because it would export symbols that
 are only needed for other ports.


Can we make the macro starter and specify ports under which a given symbol
needs to be exported? e.g. WEBCORE_EXPORT(MAC, QT)

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Alexey Proskuryakov

30.01.2013, в 17:14, Dirk Pranke dpra...@chromium.org написал(а):

 CMake was originally considered a non-starter for chromium since the
 XCode and VS projects it produced didn't look or feel like native
 projects.

I think that this is the key consideration here. Whatever the pains of 
modifying multiple build systems files are, reading and - to a lesser extent - 
modifying actual code is the most important activity to optimize for.

It's not so helpful to have an easy way to add code if the only reason you are 
adding it is that you could not easily navigate the code base to find an 
already existing solution.

To me personally, this means that Xcode project files need to be fully usable.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Media Server Development

2013-01-31 Thread Arunprasad RajKumar
Basically WebKit runs in the event thread(main thread) of the porting(qt,gtk). 
WebKit node data structures will be created and destroyed only from the 
mainthread. Also WebKit's timer scheduled from the main thread. Are u running 
multiple instance of webview from multiple  threads? If so it shouldn't be done 
like tat. You can check the thread id of duration and destrutor's caller if u r 
not sure.

Sent from my Xperia™ smartphone 

Kiran K kiran.pe...@gmail.com wrote:

HI All,

I am working on QtWebKit  on Media Server development. Basic Idea is to run
Gstreamer in seperate process which acts like a Media server. The calls
from WebKit in MediaPlayerPrivateGStreamer.cpp are routed to Media Server
via DBUS. Media Server implements the methods in
MediaPlayerPrivateGStreamer class. I am basically doing this to have
control over the resources like maximum playback instances, hw codec
control etc. I am able to do achieve playback to some extent. I am facing
some problems  (race conditions) especially when deleting playback
instance. From the logs i concluded that when duration() function is made
and is waiting for response from server, ~MediaPlayerPrivateGStreamer
destructor is getting called. (some times vice versa too). I am suspecting
that the MediaPlayer object is being shared between two threads (or across
timers). Can anybody give me some pointers about HTMLMediaElement  and the
timers involved? Any help is appreciated.

Thanks,
Arun

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Hugo Parente Lima
On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
 On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote:
  On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote:
  Thanks for sharing this.
  
  On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:
  
  I wish we only had one build system (it were easy to add/remove/move
  files).
  
  I believe changes like http://trac.webkit.org/changeset/74849 are an
  unhealthy sign for the project.  Adam is not the only person who has
  chosen
  to empty files instead of removing them.  The pain of updating 8 build
  system is so great, we jump through hoops to avoid it.  Which means it
  took
  us months to move JavaScriptCore/wtf to WTF, and will take us years to
  kill
  WebCore/platform.
  
  
  +1
  
  This is a hard problem.  It is a problem worth solving.
  
  Do you have more thoughts on this, particularly since you know quite well
  how both Xcode and gyp work?
  
  I suspect this is one of those things that it would be hard to achieve
  consensus on since there are so many stakeholders.  But it may be
  fruitful
  to have a what if discussion about what this might look like.
  
  I think we can solve this problem if we agree that we want to. I think
  we haven't in the past mostly because we couldn't reach a consensus
  that it was worth solving enough to really try.
  
  I would love to see this fixed and would be glad to work on it. I
  think we should at least pursue this far enough to fully understand
  what our options are and what the costs and tradeoffs might be; does
  anyone disagree, and is anyone else willing to help pitch in?
  
  I think there are several possible ways we could solve this. One would
  be to switch to a common meta-build system. My understanding is that
  Apple's internal production build processes impose certain constraints
  here that I don't fully understand, but I know we've discussed the
  possibility of checking in generated project files as a workaround.
  Maybe there are other options as well to those constraints? I would
  love to discuss this further w/ someone from Apple ...
 
 It's far simplest for us if:
 (a) There is an Xcode project (or a Makefile) that builds the Mac port
 checked in to source control. (b) The generated project invokes only tools
 that are part of the default Mac OS X install.
 
 It may not be completely impossible to violate these requirements but it
 will require a lot of bureaucracy.
  (Also, just to get this out of the way, I don't think gyp needs to be
  the solution).
  
  Another alternative would be to write a script that did support at
  least the common use cases (add/move/delete files). There have been
  attempts in the past, but they have foundered on at least some
  perceived skepticism over how well this would work w/ XCode. That
  said, I don't think we've really pushed this to see. At some point
  this script might turn into a meta-meta-build system, which might be
  silly but also be the shortest path to the finish line.
  
  I suggest if there is interest in this we can start a new thread to
  discuss further ...
 
 My preference would be to use a common meta-build system with a comfortably
 human-readable and human-editable syntax, and checked in generated project
 files for those ports that need them.
 
 I think a key to making this work is to get Chromium and the Apple Mac port
 onto a common build system, which will probably require both Google and
 Apple ponying up at least one person to work on this project for a
 reasonable period of time.
 
 I think the plausible meta-build-systems to use would be CMake and Gyp, but
 in both cases it may be necessary to modify them to work well for everyone.
 
 I'd also like to add that I think a key related issue to common build system
 is common feature configuration. The many different ways ports control
 their feature flags is super confusing. I've long wanted to implement
 common configuration management, but have not had time.

I have a patch trying to solve this issue for CMake based ports[1], the patch 
still on going, but even a change affecting just 2-3 ports using the same build 
system is a bit hard to get a consensus, so you can imagine how hard will be 
to get a consensus over all WebKit ports.
 
[1] https://bugs.webkit.org/show_bug.cgi?id=103162

 Cheers,
 Maciej
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Media Server Development

2013-01-31 Thread John Yani
Hi Kiran,

I'm afraid, this is not the right place to ask questions like that. Try
asking webkit-help.

On 31 January 2013 19:34, Kiran K kiran.pe...@gmail.com wrote:

 HI All,

 I am working on QtWebKit  on Media Server development. Basic Idea is to
 run Gstreamer in seperate process which acts like a Media server. The
 calls  from WebKit in MediaPlayerPrivateGStreamer.cpp are routed to Media
 Server via DBUS. Media Server implements the methods in
 MediaPlayerPrivateGStreamer class. I am basically doing this to have
 control over the resources like maximum playback instances, hw codec
 control etc. I am able to do achieve playback to some extent. I am facing
 some problems  (race conditions) especially when deleting playback
 instance. From the logs i concluded that when duration() function is made
 and is waiting for response from server, ~MediaPlayerPrivateGStreamer
 destructor is getting called. (some times vice versa too). I am suspecting
 that the MediaPlayer object is being shared between two threads (or across
 timers). Can anybody give me some pointers about HTMLMediaElement  and the
 timers involved? Any help is appreciated.

 Thanks,
 Arun


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Dirk Pranke
On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima
hugo.l...@openbossa.org wrote:
 On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
 On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote:
  On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote:
  Thanks for sharing this.
 
  On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:
 
  I wish we only had one build system (it were easy to add/remove/move
  files).
 
  I believe changes like http://trac.webkit.org/changeset/74849 are an
  unhealthy sign for the project.  Adam is not the only person who has
  chosen
  to empty files instead of removing them.  The pain of updating 8 build
  system is so great, we jump through hoops to avoid it.  Which means it
  took
  us months to move JavaScriptCore/wtf to WTF, and will take us years to
  kill
  WebCore/platform.
 
 
  +1
 
  This is a hard problem.  It is a problem worth solving.
 
  Do you have more thoughts on this, particularly since you know quite well
  how both Xcode and gyp work?
 
  I suspect this is one of those things that it would be hard to achieve
  consensus on since there are so many stakeholders.  But it may be
  fruitful
  to have a what if discussion about what this might look like.
 
  I think we can solve this problem if we agree that we want to. I think
  we haven't in the past mostly because we couldn't reach a consensus
  that it was worth solving enough to really try.
 
  I would love to see this fixed and would be glad to work on it. I
  think we should at least pursue this far enough to fully understand
  what our options are and what the costs and tradeoffs might be; does
  anyone disagree, and is anyone else willing to help pitch in?
 
  I think there are several possible ways we could solve this. One would
  be to switch to a common meta-build system. My understanding is that
  Apple's internal production build processes impose certain constraints
  here that I don't fully understand, but I know we've discussed the
  possibility of checking in generated project files as a workaround.
  Maybe there are other options as well to those constraints? I would
  love to discuss this further w/ someone from Apple ...

 It's far simplest for us if:
 (a) There is an Xcode project (or a Makefile) that builds the Mac port
 checked in to source control. (b) The generated project invokes only tools
 that are part of the default Mac OS X install.

 It may not be completely impossible to violate these requirements but it
 will require a lot of bureaucracy.
  (Also, just to get this out of the way, I don't think gyp needs to be
  the solution).
 
  Another alternative would be to write a script that did support at
  least the common use cases (add/move/delete files). There have been
  attempts in the past, but they have foundered on at least some
  perceived skepticism over how well this would work w/ XCode. That
  said, I don't think we've really pushed this to see. At some point
  this script might turn into a meta-meta-build system, which might be
  silly but also be the shortest path to the finish line.
 
  I suggest if there is interest in this we can start a new thread to
  discuss further ...

 My preference would be to use a common meta-build system with a comfortably
 human-readable and human-editable syntax, and checked in generated project
 files for those ports that need them.

 I think a key to making this work is to get Chromium and the Apple Mac port
 onto a common build system, which will probably require both Google and
 Apple ponying up at least one person to work on this project for a
 reasonable period of time.

 I think the plausible meta-build-systems to use would be CMake and Gyp, but
 in both cases it may be necessary to modify them to work well for everyone.

 I'd also like to add that I think a key related issue to common build system
 is common feature configuration. The many different ways ports control
 their feature flags is super confusing. I've long wanted to implement
 common configuration management, but have not had time.

 I have a patch trying to solve this issue for CMake based ports[1], the patch
 still on going, but even a change affecting just 2-3 ports using the same 
 build
 system is a bit hard to get a consensus, so you can imagine how hard will be
 to get a consensus over all WebKit ports.

 [1] https://bugs.webkit.org/show_bug.cgi?id=103162


This is slightly off-topic, but I had thought that no one was actually
using CMake; maybe I was mistaken and just none of the ports that
build on webkit.org are? It looks like Blackberry and maybe a WinCE
port uses CMake? Anyone else?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Patrick Gansterer

Am 31.01.2013 um 21:07 schrieb Dirk Pranke:

 On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima
 hugo.l...@openbossa.org wrote:
 On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
 On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote:
 On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote:
 Thanks for sharing this.
 
 On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:
 
 I wish we only had one build system (it were easy to add/remove/move
 files).
 
 I believe changes like http://trac.webkit.org/changeset/74849 are an
 unhealthy sign for the project.  Adam is not the only person who has
 chosen
 to empty files instead of removing them.  The pain of updating 8 build
 system is so great, we jump through hoops to avoid it.  Which means it
 took
 us months to move JavaScriptCore/wtf to WTF, and will take us years to
 kill
 WebCore/platform.
 
 
 +1
 
 This is a hard problem.  It is a problem worth solving.
 
 Do you have more thoughts on this, particularly since you know quite well
 how both Xcode and gyp work?
 
 I suspect this is one of those things that it would be hard to achieve
 consensus on since there are so many stakeholders.  But it may be
 fruitful
 to have a what if discussion about what this might look like.
 
 I think we can solve this problem if we agree that we want to. I think
 we haven't in the past mostly because we couldn't reach a consensus
 that it was worth solving enough to really try.
 
 I would love to see this fixed and would be glad to work on it. I
 think we should at least pursue this far enough to fully understand
 what our options are and what the costs and tradeoffs might be; does
 anyone disagree, and is anyone else willing to help pitch in?
 
 I think there are several possible ways we could solve this. One would
 be to switch to a common meta-build system. My understanding is that
 Apple's internal production build processes impose certain constraints
 here that I don't fully understand, but I know we've discussed the
 possibility of checking in generated project files as a workaround.
 Maybe there are other options as well to those constraints? I would
 love to discuss this further w/ someone from Apple ...
 
 It's far simplest for us if:
 (a) There is an Xcode project (or a Makefile) that builds the Mac port
 checked in to source control. (b) The generated project invokes only tools
 that are part of the default Mac OS X install.
 
 It may not be completely impossible to violate these requirements but it
 will require a lot of bureaucracy.
 (Also, just to get this out of the way, I don't think gyp needs to be
 the solution).
 
 Another alternative would be to write a script that did support at
 least the common use cases (add/move/delete files). There have been
 attempts in the past, but they have foundered on at least some
 perceived skepticism over how well this would work w/ XCode. That
 said, I don't think we've really pushed this to see. At some point
 this script might turn into a meta-meta-build system, which might be
 silly but also be the shortest path to the finish line.
 
 I suggest if there is interest in this we can start a new thread to
 discuss further ...
 
 My preference would be to use a common meta-build system with a comfortably
 human-readable and human-editable syntax, and checked in generated project
 files for those ports that need them.
 
 I think a key to making this work is to get Chromium and the Apple Mac port
 onto a common build system, which will probably require both Google and
 Apple ponying up at least one person to work on this project for a
 reasonable period of time.
 
 I think the plausible meta-build-systems to use would be CMake and Gyp, but
 in both cases it may be necessary to modify them to work well for everyone.
 
 I'd also like to add that I think a key related issue to common build system
 is common feature configuration. The many different ways ports control
 their feature flags is super confusing. I've long wanted to implement
 common configuration management, but have not had time.
 
 I have a patch trying to solve this issue for CMake based ports[1], the patch
 still on going, but even a change affecting just 2-3 ports using the same 
 build
 system is a bit hard to get a consensus, so you can imagine how hard will be
 to get a consensus over all WebKit ports.
 
 [1] https://bugs.webkit.org/show_bug.cgi?id=103162
 
 
 This is slightly off-topic, but I had thought that no one was actually
 using CMake; maybe I was mistaken and just none of the ports that
 build on webkit.org are? It looks like Blackberry and maybe a WinCE
 port uses CMake? Anyone else?

EFL uses CMake too.
4 EFL bots @ http://build.webkit.org
1 WinCE bot @ http://build.webkit.org
1 EFL bot as EWS

-- Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Dirk Pranke
On Thu, Jan 31, 2013 at 12:10 PM, Patrick Gansterer par...@paroga.com wrote:

 Am 31.01.2013 um 21:07 schrieb Dirk Pranke:

 On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima
 hugo.l...@openbossa.org wrote:
 On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
 On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote:
 On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote:
 Thanks for sharing this.

 On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:

 I wish we only had one build system (it were easy to add/remove/move
 files).

 I believe changes like http://trac.webkit.org/changeset/74849 are an
 unhealthy sign for the project.  Adam is not the only person who has
 chosen
 to empty files instead of removing them.  The pain of updating 8 build
 system is so great, we jump through hoops to avoid it.  Which means it
 took
 us months to move JavaScriptCore/wtf to WTF, and will take us years to
 kill
 WebCore/platform.


 +1

 This is a hard problem.  It is a problem worth solving.

 Do you have more thoughts on this, particularly since you know quite well
 how both Xcode and gyp work?

 I suspect this is one of those things that it would be hard to achieve
 consensus on since there are so many stakeholders.  But it may be
 fruitful
 to have a what if discussion about what this might look like.

 I think we can solve this problem if we agree that we want to. I think
 we haven't in the past mostly because we couldn't reach a consensus
 that it was worth solving enough to really try.

 I would love to see this fixed and would be glad to work on it. I
 think we should at least pursue this far enough to fully understand
 what our options are and what the costs and tradeoffs might be; does
 anyone disagree, and is anyone else willing to help pitch in?

 I think there are several possible ways we could solve this. One would
 be to switch to a common meta-build system. My understanding is that
 Apple's internal production build processes impose certain constraints
 here that I don't fully understand, but I know we've discussed the
 possibility of checking in generated project files as a workaround.
 Maybe there are other options as well to those constraints? I would
 love to discuss this further w/ someone from Apple ...

 It's far simplest for us if:
 (a) There is an Xcode project (or a Makefile) that builds the Mac port
 checked in to source control. (b) The generated project invokes only tools
 that are part of the default Mac OS X install.

 It may not be completely impossible to violate these requirements but it
 will require a lot of bureaucracy.
 (Also, just to get this out of the way, I don't think gyp needs to be
 the solution).

 Another alternative would be to write a script that did support at
 least the common use cases (add/move/delete files). There have been
 attempts in the past, but they have foundered on at least some
 perceived skepticism over how well this would work w/ XCode. That
 said, I don't think we've really pushed this to see. At some point
 this script might turn into a meta-meta-build system, which might be
 silly but also be the shortest path to the finish line.

 I suggest if there is interest in this we can start a new thread to
 discuss further ...

 My preference would be to use a common meta-build system with a comfortably
 human-readable and human-editable syntax, and checked in generated project
 files for those ports that need them.

 I think a key to making this work is to get Chromium and the Apple Mac port
 onto a common build system, which will probably require both Google and
 Apple ponying up at least one person to work on this project for a
 reasonable period of time.

 I think the plausible meta-build-systems to use would be CMake and Gyp, but
 in both cases it may be necessary to modify them to work well for everyone.

 I'd also like to add that I think a key related issue to common build 
 system
 is common feature configuration. The many different ways ports control
 their feature flags is super confusing. I've long wanted to implement
 common configuration management, but have not had time.

 I have a patch trying to solve this issue for CMake based ports[1], the 
 patch
 still on going, but even a change affecting just 2-3 ports using the same 
 build
 system is a bit hard to get a consensus, so you can imagine how hard will be
 to get a consensus over all WebKit ports.

 [1] https://bugs.webkit.org/show_bug.cgi?id=103162


 This is slightly off-topic, but I had thought that no one was actually
 using CMake; maybe I was mistaken and just none of the ports that
 build on webkit.org are? It looks like Blackberry and maybe a WinCE
 port uses CMake? Anyone else?

 EFL uses CMake too.
 4 EFL bots @ http://build.webkit.org
 1 WinCE bot @ http://build.webkit.org
 1 EFL bot as EWS


Ah, I thought EFL was using Autotools. Thanks for the correction.

-- Dirk
___
webkit-dev 

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Hugo Parente Lima
On Thursday, January 31, 2013 06:14:20 PM Patrick Gansterer wrote:
 Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
  On Jan 31, 2013, at 1:56 AM, Patrick Gansterer par...@paroga.com wrote:
  Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
  On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org
  wrote: Another option is to add a webkit-patch command for modifying
  the build files. That way, the syntax doesn't need to be overly human
  friendly. There was also some attempt to write a tool to add files
  automatically: https://bugs.webkit.org/show_bug.cgi?ida772  I would
  expect that such a tool becomes easier if it would only modify one
  source of truth and generates all other artifacts such as Xcode
  projects from it.
 
  I don't want build file's syntax to be so human unfriendly that I need a
  tool
for it.
 
  Often times, these syntax problems can be improved dramatically by
  simple changes. e.g. we had a similar discussion about TestExpectation
  syntax, and I'm much happier with the new syntax even though the new
  syntax is functionally equivalent to the old one, and two syntaxes are
  very similar.
 
  On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:
  I’ve experimented with this in the past and you’re right that it
  shouldn’t be particularly difficult to do. However, I suspect that the
  task would be similar in scope to defining an improved syntax for gyp.
  And if the syntax is the primary sticking point with gyp then it’d seem
  preferable to tackle initially.
 
  Yeah. In fact, we can just come up with whatever syntax we like and
  convert it to the existing gyp format if the syntax was the biggest
  issue.
  Do we want to define the whole build system (including inform
tion how to
  invoke the generators) with the new system, or is a simple list for
  the input files sufficient? IMHO adding a new generator build step
  happens very rarely. So maybe we can spit the input file list (mainly
  *.cpp and *.idl) into new files. Then GYP and CMake can read them and
  generate the build system out of them directly (like they to already
  today) instead of listing the files in the *.gpyi and *.cmake. This
  might work for other systems like qmake too. For XCode we can maybe have
  a template XCode project and generate the work XCode project with a
  script. This script then only need to fill in the files from the input
  file list into the template XCode project. Defining the feature flags
  can be done like Maciej suggested with Port.h files.
  I think it would be better to adapt an existing meta build system to our
  needs than to make one from scratch, unless we find that completely
  impractical.
 
  I
 particular, gyp and cmake both know how to handle generated sources,
  and while it may not be super common to make a new type of generated
  source, it's bad for hackability of the project of doing so is super
  hard. We get a lot of hackability benefits from using various kinds of
  generated sources, many first introduced in the days when we had a lot
  fewer build systems. So in my mind, they are already ahead of a
  hypothetical simple system.
 Do you want to kick the requirements of the smaller ports from trunk or do
 you think that e.g. a qmake generate for GYP makes sense? AFAIK e.g.
 QtWebKit is shipped with Qt, which uses qmake as build system, where
 CMake/GYP is not an option.

 I completely agree that creating a new meta meta build system isn't a good
 idea, but sharing the common parts (which reduce the daily productivity)
 might be a step in the right direction. Using simple text files which
 contain the list of files (like the gpyi files already do tod
y) isn't a
 new build system. It only offers the existing meta build systems (CMake,
 GYP, autotools, qmake) to use a common base.

I agree, common build system on WebKit is an utopia, create a new meta build
system isn't a good idea, so the only plausible option is to unify way we
add/remove/modify files from the build. Create a script to do this on all build
system is yet another utopia, so again, the only option is to have plain text
files.

Going a bit further on this idea, would be nice to also have conditionals on
these plain text files to cover the use case of e.g. add foo.cpp to the build
when ENABLE_FOO or WTF_USE_FOO is on would be even better, a script would be
called passing all ENABLE, USE, HAVE, etc.. flags and returning a list of files,
the only question is if all current build system would support such dynamic
source file list, CMake does :-)

 The remaining build systems can be ported to one of these systems or be
 adopted to use this file lists too.


 -- Patrick

pgpVpcWAo2RvL.pgp
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Dirk Pranke
On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer par...@paroga.com wrote:

 Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:


 On Jan 31, 2013, at 1:56 AM, Patrick Gansterer par...@paroga.com wrote:

 Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:

 On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org
 wrote:

 Another option is to add a webkit-patch command for modifying the build
 files. That way, the syntax doesn't need to be overly human friendly. There
 was also some attempt to write a tool to add files automatically:
 https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a
 tool becomes easier if it would only modify one source of truth and
 generates all other artifacts such as Xcode projects from it.


 I don't want build file's syntax to be so human unfriendly that I need a
 tool for it.

 Often times, these syntax problems can be improved dramatically by simple
 changes. e.g. we had a similar discussion about TestExpectation syntax, and
 I'm much happier with the new syntax even though the new syntax is
 functionally equivalent to the old one, and two syntaxes are very similar.

 On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:

 I’ve experimented with this in the past and you’re right that it shouldn’t
 be particularly difficult to do. However, I suspect that the task would be
 similar in scope to defining an improved syntax for gyp. And if the syntax
 is the primary sticking point with gyp then it’d seem preferable to tackle
 initially.


 Yeah. In fact, we can just come up with whatever syntax we like and convert
 it to the existing gyp format if the syntax was the biggest issue.


 Do we want to define the whole build system (including information how to
 invoke the generators) with the new system, or is a simple list for the
 input files sufficient? IMHO adding a new generator build step happens very
 rarely. So maybe we can spit the input file list (mainly *.cpp and *.idl)
 into new files.
 Then GYP and CMake can read them and generate the build system out of them
 directly (like they to already today) instead of listing the files in the
 *.gpyi and *.cmake. This might work for other systems like qmake too.
 For XCode we can maybe have a template XCode project and generate the
 work XCode project with a script. This script then only need to fill in
 the files from the input file list into the template XCode project.
 Defining the feature flags can be done like Maciej suggested with Port.h
 files.


 I think it would be better to adapt an existing meta build system to our
 needs than to make one from scratch, unless we find that completely
 impractical.

 In particular, gyp and cmake both know how to handle generated sources, and
 while it may not be super common to make a new type of generated source,
 it's bad for hackability of the project of doing so is super hard. We get a
 lot of hackability benefits from using various kinds of generated sources,
 many first introduced in the days when we had a lot fewer build systems. So
 in my mind, they are already ahead of a hypothetical simple system.


 Do you want to kick the requirements of the smaller ports from trunk or do
 you think that e.g. a qmake generate for GYP makes sense?
 AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system,
 where CMake/GYP is not an option.


It could certainly make sense for us to add Autotools and Qmake
generators to GYP; I'm less certain if a CMake generator makes much
sense, but I haven't thought about it as much. I'm not super familiar
with any of these three tools, so I could be dead wrong.

 I completely agree that creating a new meta meta build system isn't a good
 idea, but sharing the common parts (which reduce the daily productivity)
 might be a step in the right direction. Using simple text files which
 contain the list of files (like the gpyi files already do today) isn't a new
 build system. It only offers the existing meta build systems (CMake, GYP,
 autotools, qmake) to use a common base.

 The remaining build systems can be ported to one of these systems or be
 adopted to use this file lists too.

 -- Patrick

I suspect that we would quickly find that we would want some sort of
support for conditionals and/or file inclusion in our simple text
files, at which point you basically get a meta-meta-build system :).
I don't actually think such a thing is that bad of an idea, but it's
all in the details.

I would like to find a solution where all of the ports were able to
retain integration with their native build environments one way or
another.

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Ryosuke Niwa
On Thu, Jan 31, 2013 at 12:31 PM, Dirk Pranke dpra...@chromium.org wrote:

 On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer par...@paroga.com
 wrote:
 
  Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
 
 
  On Jan 31, 2013, at 1:56 AM, Patrick Gansterer par...@paroga.com
 wrote:
 
  Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
 
  On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org
  wrote:
 
  Another option is to add a webkit-patch command for modifying the build
  files. That way, the syntax doesn't need to be overly human friendly.
 There
  was also some attempt to write a tool to add files automatically:
  https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that
 such a
  tool becomes easier if it would only modify one source of truth and
  generates all other artifacts such as Xcode projects from it.
 
 
  I don't want build file's syntax to be so human unfriendly that I need a
  tool for it.
 
  Often times, these syntax problems can be improved dramatically by simple
  changes. e.g. we had a similar discussion about TestExpectation syntax,
 and
  I'm much happier with the new syntax even though the new syntax is
  functionally equivalent to the old one, and two syntaxes are very
 similar.
 
  On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:
 
  I’ve experimented with this in the past and you’re right that it
 shouldn’t
  be particularly difficult to do. However, I suspect that the task would
 be
  similar in scope to defining an improved syntax for gyp. And if the
 syntax
  is the primary sticking point with gyp then it’d seem preferable to
 tackle
  initially.
 
 
  Yeah. In fact, we can just come up with whatever syntax we like and
 convert
  it to the existing gyp format if the syntax was the biggest issue.
 
 
  Do we want to define the whole build system (including information how to
  invoke the generators) with the new system, or is a simple list for the
  input files sufficient? IMHO adding a new generator build step happens
 very
  rarely. So maybe we can spit the input file list (mainly *.cpp and
 *.idl)
  into new files.
  Then GYP and CMake can read them and generate the build system out of
 them
  directly (like they to already today) instead of listing the files in the
  *.gpyi and *.cmake. This might work for other systems like qmake too.
  For XCode we can maybe have a template XCode project and generate the
  work XCode project with a script. This script then only need to fill in
  the files from the input file list into the template XCode project.
  Defining the feature flags can be done like Maciej suggested with
 Port.h
  files.
 
 
  I think it would be better to adapt an existing meta build system to our
  needs than to make one from scratch, unless we find that completely
  impractical.
 
  In particular, gyp and cmake both know how to handle generated sources,
 and
  while it may not be super common to make a new type of generated source,
  it's bad for hackability of the project of doing so is super hard. We
 get a
  lot of hackability benefits from using various kinds of generated
 sources,
  many first introduced in the days when we had a lot fewer build systems.
 So
  in my mind, they are already ahead of a hypothetical simple system.
 
 
  Do you want to kick the requirements of the smaller ports from trunk or
 do
  you think that e.g. a qmake generate for GYP makes sense?
  AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system,
  where CMake/GYP is not an option.
 

 It could certainly make sense for us to add Autotools and Qmake
 generators to GYP; I'm less certain if a CMake generator makes much
 sense, but I haven't thought about it as much. I'm not super familiar
 with any of these three tools, so I could be dead wrong.


I think making Autotools and Qmake use GYP will be a huge win even if we
couldn't make Xcodeproj and CMake use GYP at the end. Having GYP + CMake +
Xcodeproj is much better than having Autotools and Qmake on top of that.

I don't think we need to necessarily unify all build systems. Reducing the
number of build systems is a worthwhile goal on its own merit.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Nico Weber
This is a lovely discussion to have every now and then :-)

Maybe the file add/move/delete tool that someone wrote could land
without xcode support for now? Then the pain of moving files is
reduced to two systems (xcode and everyone else), and that's something
that's at least tractable.

Nico

On Thu, Jan 31, 2013 at 12:31 PM, Dirk Pranke dpra...@chromium.org wrote:
 On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer par...@paroga.com wrote:

 Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:


 On Jan 31, 2013, at 1:56 AM, Patrick Gansterer par...@paroga.com wrote:

 Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:

 On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org
 wrote:

 Another option is to add a webkit-patch command for modifying the build
 files. That way, the syntax doesn't need to be overly human friendly. There
 was also some attempt to write a tool to add files automatically:
 https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a
 tool becomes easier if it would only modify one source of truth and
 generates all other artifacts such as Xcode projects from it.


 I don't want build file's syntax to be so human unfriendly that I need a
 tool for it.

 Often times, these syntax problems can be improved dramatically by simple
 changes. e.g. we had a similar discussion about TestExpectation syntax, and
 I'm much happier with the new syntax even though the new syntax is
 functionally equivalent to the old one, and two syntaxes are very similar.

 On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:

 I’ve experimented with this in the past and you’re right that it shouldn’t
 be particularly difficult to do. However, I suspect that the task would be
 similar in scope to defining an improved syntax for gyp. And if the syntax
 is the primary sticking point with gyp then it’d seem preferable to tackle
 initially.


 Yeah. In fact, we can just come up with whatever syntax we like and convert
 it to the existing gyp format if the syntax was the biggest issue.


 Do we want to define the whole build system (including information how to
 invoke the generators) with the new system, or is a simple list for the
 input files sufficient? IMHO adding a new generator build step happens very
 rarely. So maybe we can spit the input file list (mainly *.cpp and *.idl)
 into new files.
 Then GYP and CMake can read them and generate the build system out of them
 directly (like they to already today) instead of listing the files in the
 *.gpyi and *.cmake. This might work for other systems like qmake too.
 For XCode we can maybe have a template XCode project and generate the
 work XCode project with a script. This script then only need to fill in
 the files from the input file list into the template XCode project.
 Defining the feature flags can be done like Maciej suggested with Port.h
 files.


 I think it would be better to adapt an existing meta build system to our
 needs than to make one from scratch, unless we find that completely
 impractical.

 In particular, gyp and cmake both know how to handle generated sources, and
 while it may not be super common to make a new type of generated source,
 it's bad for hackability of the project of doing so is super hard. We get a
 lot of hackability benefits from using various kinds of generated sources,
 many first introduced in the days when we had a lot fewer build systems. So
 in my mind, they are already ahead of a hypothetical simple system.


 Do you want to kick the requirements of the smaller ports from trunk or do
 you think that e.g. a qmake generate for GYP makes sense?
 AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system,
 where CMake/GYP is not an option.


 It could certainly make sense for us to add Autotools and Qmake
 generators to GYP; I'm less certain if a CMake generator makes much
 sense, but I haven't thought about it as much. I'm not super familiar
 with any of these three tools, so I could be dead wrong.

 I completely agree that creating a new meta meta build system isn't a good
 idea, but sharing the common parts (which reduce the daily productivity)
 might be a step in the right direction. Using simple text files which
 contain the list of files (like the gpyi files already do today) isn't a new
 build system. It only offers the existing meta build systems (CMake, GYP,
 autotools, qmake) to use a common base.

 The remaining build systems can be ported to one of these systems or be
 adopted to use this file lists too.

 -- Patrick

 I suspect that we would quickly find that we would want some sort of
 support for conditionals and/or file inclusion in our simple text
 files, at which point you basically get a meta-meta-build system :).
 I don't actually think such a thing is that bad of an idea, but it's
 all in the details.

 I would like to find a solution where all of the ports were able to
 retain integration with their native build environments one way or
 another.

 -- Dirk
 

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Ryosuke Niwa
See
https://bugs.webkit.org/show_bug.cgi?id=61773
https://bugs.webkit.org/show_bug.cgi?id=64149


On Thu, Jan 31, 2013 at 12:36 PM, Nico Weber tha...@chromium.org wrote:

 This is a lovely discussion to have every now and then :-)

 Maybe the file add/move/delete tool that someone wrote could land
 without xcode support for now? Then the pain of moving files is
 reduced to two systems (xcode and everyone else), and that's something
 that's at least tractable.

 Nico

 On Thu, Jan 31, 2013 at 12:31 PM, Dirk Pranke dpra...@chromium.org
 wrote:
  On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer par...@paroga.com
 wrote:
 
  Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
 
 
  On Jan 31, 2013, at 1:56 AM, Patrick Gansterer par...@paroga.com
 wrote:
 
  Am 31.01.2013 um 10:37 schrieb
 - R. Niwa
 :
 
  On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org
  wrote:
 
  Another option is to add a webkit-patch command for modifying the build
  files. That way, the syntax doesn't need to be overly human friendly.
 There
  was also some attempt to write a tool to add files automatically:
  https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that
 such a
  tool becomes easier if it would only modify one source of truth and
  generates all other artifacts such as Xcode projects from it.
 
 
  I don't want build file's syntax to be so human unfriendly that I need a
  tool for it.
 
  Often times, these syntax problems can be improved dramatically by
 simple
  changes. e.g. we had a similar discussion about TestExpectation syntax,
 and
  I'm much happier with the new syntax even though the new syntax is
  functionally equivalent to the old one, and two syntaxes are very
 similar.
 
  On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:
 
  I’ve experimented with this in the past and you’re right that it
 shouldn’t
  be particularly difficult to do. However, I suspect that the task
 would be
  similar in scope to defining an improved syntax for gyp. And if the
 syntax
  is the primary sticking point with gyp then it’d seem preferable to
 tackle
  initially.
 
 
  Yeah. In fact, we can just come up with whatever syntax we like and
 convert
  it to the existing gyp format if the syntax was the biggest issue.
 
 
  Do we want to define the whole build system (including information how
 to
  invoke the generators) with the new system, or is a simple list for
 the
  input files sufficient? IMHO adding a new generator build step happens
 very
  rarely. So maybe we can spit the input file list (mainly *.cpp and
 *.idl)
  into new files.
  Then GYP and CMake can read them and generate the build system out of
 them
  directly (like they to already today) instead of listing the files in
 the
  *.gpyi and *.cmake. This might work for other systems like qmake too.
  For XCode we can maybe have a template XCode project and generate the
  work XCode project with a script. This script then only need to fill
 in
  the files from the input file list into the template XCode project.
  Defining the feature flags can be done like Maciej suggested with
 Port.h
  files.
 
 
  I think it would be better to adapt an existing meta build system to our
  needs than to make one from scratch, unless we find that completely
  impractical.
 
  In particular, gyp and cmake both know how to handle generated sources,
 and
  while it may not be super common to make a new type of generated source,
  it's bad for hackability of the project of doing so is super hard. We
 get a
  lot of hackability benefits from using various kinds of generated
 sources,
  many first introduced in the days when we had a lot fewer build
 systems. So
  in my mind, they are already ahead of a hypothetical simple system.
 
 
  Do you want to kick the requirements of the smaller ports from trunk or
 do
  you think that e.g. a qmake generate for GYP makes sense?
  AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build
 system,
  where CMake/GYP is not an option.
 
 
  It could certainly make sense for us to add Autotools and Qmake
  generators to GYP; I'm less certain if a CMake generator makes much
  sense, but I haven't thought about it as much. I'm not super familiar
  with any of these three tools, so I could be dead wrong.
 
  I completely agree that creating a new meta meta build system isn't a
 good
  idea, but sharing the common parts (which reduce the daily productivity)
  might be a step in the right direction. Using simple text files which
  contain the list of files (like the gpyi files already do today) isn't
 a new
  build system. It only offers the existing meta build systems (CMake,
 GYP,
  autotools, qmake) to use a common base.
 
  The remaining build systems can be ported to one of these systems or be
  adopted to use this file lists too.
 
  -- Patrick
 
  I suspect that we would quickly find that we would want some sort of
  support for conditionals and/or file inclusion in our simple text
  files, at which 

Re: [webkit-dev] Removing ENABLE(WEB_INTENTS) code

2013-01-31 Thread Edward O'Connor
Hi Nico,

You wrote:

 I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know,
 nobody ever shipped this and nobody intents to.

Sounds good.


Ted
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Dirk Pranke
On Thu, Jan 31, 2013 at 9:48 AM, Ryosuke Niwa rn...@webkit.org wrote:
 On Thu, Jan 31, 2013 at 9:43 AM, Alexey Proskuryakov a...@apple.com wrote:


 31.01.2013, в 0:17, Ryosuke Niwa rn...@webkit.org написал(а):

 I did it for WTF and JSC with kevino@.
 https://bugs.webkit.org/show_bug.cgi?id=72855
 I hope I had had time to extend the work to WebCore, which was my
 original goal :-/

 I did it through an automation but the tool was so slow and hacky that it
 was not capable for large WebCore codebase.

 Seeing that the number of exported symbol is about 2700, manual work with
 regular expression will also work
 if it is OK to do the work incrementally... and if you are patient enough
 :-)


 2700 is a lot of symbols to export! Perhaps we can reduce the number of
 exported symbols? For example, we can move more code from WebKit into
 WebCore to share more code between ports so that the API surface WebCore has
 to expose will be smaller and more well defined.


 One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
 the number of exports for each port, because it would export symbols that
 are only needed for other ports.


I'm not sure I understand the concern here. Is the idea that some
ports might build WebCore as a DLL (and need exports) and others
wouldn't? Or the idea that the API that is needed to be exported might
vary from port to port in such a way that too many symbols for WebCore
might be exported on some ports?


 Can we make the macro starter and specify ports under which a given symbol
 needs to be exported? e.g. WEBCORE_EXPORT(MAC, QT)


I'm not sure how this helps, but I think that's because of my previous
comment. I could see something like this maybe being needed in my
later scenario (where MAC might need a symbol exported from WebCore
that Qt needed to keep from being exported)?

Is that a hard requirement, or an optimization?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Alexey Proskuryakov

31.01.2013, в 14:45, Dirk Pranke dpra...@chromium.org написал(а):

 One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
 the number of exports for each port, because it would export symbols that
 are only needed for other ports.
 
 
 I'm not sure I understand the concern here. Is the idea that some
 ports might build WebCore as a DLL (and need exports) and others
 wouldn't? Or the idea that the API that is needed to be exported might
 vary from port to port in such a way that too many symbols for WebCore
 might be exported on some ports?

The latter.

I suspect that it's somewhat less of an issue for JavaScriptCore, because its 
exports are mostly used from cross-platform code.

- WBR, Alexey Proskuryakov


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Dirk Pranke
On Thu, Jan 31, 2013 at 2:52 PM, Alexey Proskuryakov a...@apple.com wrote:

 31.01.2013, в 14:45, Dirk Pranke dpra...@chromium.org написал(а):

 One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
 the number of exports for each port, because it would export symbols that
 are only needed for other ports.


 I'm not sure I understand the concern here. Is the idea that some
 ports might build WebCore as a DLL (and need exports) and others
 wouldn't? Or the idea that the API that is needed to be exported might
 vary from port to port in such a way that too many symbols for WebCore
 might be exported on some ports?

 The latter.

 I suspect that it's somewhat less of an issue for JavaScriptCore, because its 
 exports are mostly used from cross-platform code.


I see. Some concrete examples would be helpful here (to me, at least).
What components and ports are we talking about, and what sorts of
symbols?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Alexey Proskuryakov

31.01.2013, в 14:57, Dirk Pranke dpra...@chromium.org написал(а):

 One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
 the number of exports for each port, because it would export symbols that
 are only needed for other ports.
 
 
 I'm not sure I understand the concern here. Is the idea that some
 ports might build WebCore as a DLL (and need exports) and others
 wouldn't? Or the idea that the API that is needed to be exported might
 vary from port to port in such a way that too many symbols for WebCore
 might be exported on some ports?
 
 The latter.
 
 I suspect that it's somewhat less of an issue for JavaScriptCore, because 
 its exports are mostly used from cross-platform code.
 
 
 I see. Some concrete examples would be helpful here (to me, at least).
 What components and ports are we talking about, and what sorts of
 symbols?

I don't have concrete examples, and I don't know how big an effect on 
performance increasing the number of exports would have. It's something to keep 
an eye on, not a reason to avoid trying.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Ryosuke Niwa
On Thu, Jan 31, 2013 at 2:57 PM, Dirk Pranke dpra...@chromium.org wrote:

 On Thu, Jan 31, 2013 at 2:52 PM, Alexey Proskuryakov a...@apple.com wrote:
 
  31.01.2013, в 14:45, Dirk Pranke dpra...@chromium.org написал(а):
 
  One thing to keep an eye on with WEBCORE_EXPORT is that it can
 increase
  the number of exports for each port, because it would export symbols
 that
  are only needed for other ports.
 
 
  I'm not sure I understand the concern here. Is the idea that some
  ports might build WebCore as a DLL (and need exports) and others
  wouldn't? Or the idea that the API that is needed to be exported might
  vary from port to port in such a way that too many symbols for WebCore
  might be exported on some ports?
 
  The latter.
 
  I suspect that it's somewhat less of an issue for JavaScriptCore,
 because its exports are mostly used from cross-platform code.
 

 I see. Some concrete examples would be helpful here (to me, at least).
 What components and ports are we talking about, and what sorts of
 symbols?


FWIW, there are quite few symbols exported from EditorMac.mm although of
them are if-def PLATFORM(MAC)'ed in .h anyway.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Dirk Pranke
On Thu, Jan 31, 2013 at 3:12 PM, Alexey Proskuryakov a...@webkit.org wrote:

 31.01.2013, в 14:57, Dirk Pranke dpra...@chromium.org написал(а):

 One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
 the number of exports for each port, because it would export symbols that
 are only needed for other ports.


 I'm not sure I understand the concern here. Is the idea that some
 ports might build WebCore as a DLL (and need exports) and others
 wouldn't? Or the idea that the API that is needed to be exported might
 vary from port to port in such a way that too many symbols for WebCore
 might be exported on some ports?

 The latter.

 I suspect that it's somewhat less of an issue for JavaScriptCore, because 
 its exports are mostly used from cross-platform code.


 I see. Some concrete examples would be helpful here (to me, at least).
 What components and ports are we talking about, and what sorts of
 symbols?

 I don't have concrete examples, and I don't know how big an effect on 
 performance increasing the number of exports would have. It's something to 
 keep an eye on, not a reason to avoid trying.


I'm not parsing your reply properly -- avoid trying what? A common
EXPORT macro that is set as appropriate by each port?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Alexey Proskuryakov

31.01.2013, в 15:15, Dirk Pranke dpra...@chromium.org написал(а):

 I don't have concrete examples, and I don't know how big an effect on 
 performance increasing the number of exports would have. It's something to 
 keep an eye on, not a reason to avoid trying.
 
 I'm not parsing your reply properly -- avoid trying what? A common
 EXPORT macro that is set as appropriate by each port?

Yes, you are parsing it correctly :)

- WBR, Alexey Proskuryakov


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Eric Seidel
I believe that it's a design mistake for WebCore to need to know
anything about it's embedder, more than that there is a defined set of
platform APIs and callbacks which it talks to (which should be the
exact same for every embedder).

(The export dependency dates back to the WebCore/WebKit separation,
which in my recollection was done largely to be able to isolate LGPL
code from the non-LGPL Mac WebKit layer.)

But I believe it is a mistake that WebCore changes need to care about
the possibility that different ports may export functions differently,
or even worse, that different ports may need a different set of
functions exported.

I don't recommend using a more complicated export macro, but rather
finding ways that WebCore doesn't need to care about diverging sets of
exports.

I believe most ports (with the exception of AppleWin/AppleMac) do not
build WebCore as a separate dynamic library from WebKit, which makes
exports a non-concern in the static case.

In my perfect future world, WebCore would be split into many static
libraries, and core-code - WebKit exports would be a non-issue.  And
of course, no embedder of core-code would ever expose core types, so
no exports would ever need to be marked.


On Thu, Jan 31, 2013 at 3:38 PM, Alexey Proskuryakov a...@webkit.org wrote:

 31.01.2013, в 15:15, Dirk Pranke dpra...@chromium.org написал(а):

 I don't have concrete examples, and I don't know how big an effect on 
 performance increasing the number of exports would have. It's something to 
 keep an eye on, not a reason to avoid trying.

 I'm not parsing your reply properly -- avoid trying what? A common
 EXPORT macro that is set as appropriate by each port?

 Yes, you are parsing it correctly :)

 - WBR, Alexey Proskuryakov


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Hajime Morrita
The history aside, I think it makes sense to use the export macro
specifically for Mac WebCore because

- As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit
separation.
  Other ports like GTK or Chromium build single WebKit library which has
both WebCore and WebKit API included.
  So we need to care about only Mac and Win for now.

- Mac WebKit has relatively comprehensive feature set. It covers most of
possibly exported symbols.

- The Windows toolchain allows us to use both export symbols list and
source-level annotation (the macro).
  Thus on Windows, we could use the Mac-centered export macro *and* an
export symbol list which covers Win-specific exports.

  This means that there are unused exports on Win build, but I believe it
is very few considering that Mac/Win ports has
  similar feature set, which targets Safari on each platform. (This might
be wrong assumption though - On Mac, there are
  many other WebKit embedder other than Safari.)

One exception is symbols exported for WebCoreTesting.
Fortunately, these symbols are exactly same across ports and we can use
another macro like
WEBCORE_TESTING_EXPORT for that.

--
morrita

On Fri, Feb 1, 2013 at 9:14 AM, Eric Seidel e...@webkit.org wrote:

 I believe that it's a design mistake for WebCore to need to know
 anything about it's embedder, more than that there is a defined set of
 platform APIs and callbacks which it talks to (which should be the
 exact same for every embedder).

 (The export dependency dates back to the WebCore/WebKit separation,
 which in my recollection was done largely to be able to isolate LGPL
 code from the non-LGPL Mac WebKit layer.)

 But I believe it is a mistake that WebCore changes need to care about
 the possibility that different ports may export functions differently,
 or even worse, that different ports may need a different set of
 functions exported.

 I don't recommend using a more complicated export macro, but rather
 finding ways that WebCore doesn't need to care about diverging sets of
 exports.

 I believe most ports (with the exception of AppleWin/AppleMac) do not
 build WebCore as a separate dynamic library from WebKit, which makes
 exports a non-concern in the static case.

 In my perfect future world, WebCore would be split into many static
 libraries, and core-code - WebKit exports would be a non-issue.  And
 of course, no embedder of core-code would ever expose core types, so
 no exports would ever need to be marked.


 On Thu, Jan 31, 2013 at 3:38 PM, Alexey Proskuryakov a...@webkit.org
 wrote:
 
  31.01.2013, в 15:15, Dirk Pranke dpra...@chromium.org написал(а):
 
  I don't have concrete examples, and I don't know how big an effect on
 performance increasing the number of exports would have. It's something to
 keep an eye on, not a reason to avoid trying.
 
  I'm not parsing your reply properly -- avoid trying what? A common
  EXPORT macro that is set as appropriate by each port?
 
  Yes, you are parsing it correctly :)
 
  - WBR, Alexey Proskuryakov
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Darin Fisher
It would be nice if, in the shared library build of chromium, webcore and
perhaps the modules and platform were separate DLLs.
On Jan 31, 2013 4:15 PM, Eric Seidel e...@webkit.org wrote:

 I believe that it's a design mistake for WebCore to need to know
 anything about it's embedder, more than that there is a defined set of
 platform APIs and callbacks which it talks to (which should be the
 exact same for every embedder).

 (The export dependency dates back to the WebCore/WebKit separation,
 which in my recollection was done largely to be able to isolate LGPL
 code from the non-LGPL Mac WebKit layer.)

 But I believe it is a mistake that WebCore changes need to care about
 the possibility that different ports may export functions differently,
 or even worse, that different ports may need a different set of
 functions exported.

 I don't recommend using a more complicated export macro, but rather
 finding ways that WebCore doesn't need to care about diverging sets of
 exports.

 I believe most ports (with the exception of AppleWin/AppleMac) do not
 build WebCore as a separate dynamic library from WebKit, which makes
 exports a non-concern in the static case.

 In my perfect future world, WebCore would be split into many static
 libraries, and core-code - WebKit exports would be a non-issue.  And
 of course, no embedder of core-code would ever expose core types, so
 no exports would ever need to be marked.


 On Thu, Jan 31, 2013 at 3:38 PM, Alexey Proskuryakov a...@webkit.org
 wrote:
 
  31.01.2013, в 15:15, Dirk Pranke dpra...@chromium.org написал(а):
 
  I don't have concrete examples, and I don't know how big an effect on
 performance increasing the number of exports would have. It's something to
 keep an eye on, not a reason to avoid trying.
 
  I'm not parsing your reply properly -- avoid trying what? A common
  EXPORT macro that is set as appropriate by each port?
 
  Yes, you are parsing it correctly :)
 
  - WBR, Alexey Proskuryakov
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Ryosuke Niwa
On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita morr...@chromium.orgwrote:

 The history aside, I think it makes sense to use the export macro
 specifically for Mac WebCore because

 - As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit
 separation.
   Other ports like GTK or Chromium build single WebKit library which has
 both WebCore and WebKit API included.
   So we need to care about only Mac and Win for now.

 - Mac WebKit has relatively comprehensive feature set. It covers most of
 possibly exported symbols.

 - The Windows toolchain allows us to use both export symbols list and
 source-level annotation (the macro).
   Thus on Windows, we could use the Mac-centered export macro *and* an
 export symbol list which covers Win-specific exports.

   This means that there are unused exports on Win build, but I believe it
 is very few considering that Mac/Win ports has
   similar feature set, which targets Safari on each platform. (This might
 be wrong assumption though - On Mac, there are
   many other WebKit embedder other than Safari.)

 One exception is symbols exported for WebCoreTesting.
 Fortunately, these symbols are exactly same across ports and we can use
 another macro like
 WEBCORE_TESTING_EXPORT for that.


Doesn't GTK+ port also require symbol exports for WebKit2? In particular, I
thought all symbols used in Internals need to be exported there.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Martin Robinson
On Thu, Jan 31, 2013 at 5:39 PM, Ryosuke Niwa rn...@webkit.org wrote:
 Doesn't GTK+ port also require symbol exports for WebKit2? In particular, I
 thought all symbols used in Internals need to be exported there.

WebKitGTK+ does not need to export symbols from WebCore for WebKit2,
because WebCore is built as a static convenience library. We do need
to export symbols for the Internals library because it's built as a
separate object that links against libwebkitgtk. Adding an export
macro for Internals would be great for us, since we wouldn't have to
export so many symbols via Source/autotools/symbols.filter. It would
also decrease the maintenance burden for non-GTK+ port contributors.

--Martin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-01-31 Thread Hajime Morrita
On Fri, Feb 1, 2013 at 10:39 AM, Ryosuke Niwa rn...@webkit.org wrote:

 On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita morr...@chromium.orgwrote:

 The history aside, I think it makes sense to use the export macro
 specifically for Mac WebCore because

 - As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit
 separation.
   Other ports like GTK or Chromium build single WebKit library which
 has both WebCore and WebKit API included.
   So we need to care about only Mac and Win for now.

 - Mac WebKit has relatively comprehensive feature set. It covers most of
 possibly exported symbols.

 - The Windows toolchain allows us to use both export symbols list and
 source-level annotation (the macro).
   Thus on Windows, we could use the Mac-centered export macro *and* an
 export symbol list which covers Win-specific exports.

   This means that there are unused exports on Win build, but I believe it
 is very few considering that Mac/Win ports has
   similar feature set, which targets Safari on each platform. (This might
 be wrong assumption though - On Mac, there are
   many other WebKit embedder other than Safari.)

 One exception is symbols exported for WebCoreTesting.
 Fortunately, these symbols are exactly same across ports and we can use
 another macro like
 WEBCORE_TESTING_EXPORT for that.


 Doesn't GTK+ port also require symbol exports for WebKit2? In particular,
 I thought all symbols used in Internals need to be exported there.


Ouch, I'm sorry for the unclear explanation.
This is what I meant say as one exception above. WebCoreTesting includes
Internals, which requires some exported symbols,
which could be (IMO) covered by WEBCORE_TESTING_EXPORT or some separate
macro.


 - R. Niwa


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] MIPS review requests

2013-01-31 Thread Gergely Kis
Dear WebKit Developers,

Thank you for your support in getting LLINT for MIPS accepted into trunk.

There are still a few patches that need review in order to get webkit trunk
running on MIPS:

1. DFG JIT: https://bugs.webkit.org/show_bug.cgi?id=101328
We did the changes requested by the reviewers. Actually we did 2 versions
of the patch so you can choose which one you like best. Unfortunately we
did not get any reviews since then.

2. 64bit atomic implementation:
https://bugs.webkit.org/show_bug.cgi?id=106739
We implemented 64bit atomic increment and decrement using a mutex.
Unfortunately on MIPS there is currently no better solution. The same
solution is used on Android as well. Unfortunately we did not get any more
reviews on this issue either.

3. We also have another pending patch, which is not MIPS specific, but a
fix to the style checker which should help anyone who is submitting patches
with asm() statements:
https://bugs.webkit.org/show_bug.cgi?id=101367

This patch has also attracted no review comments so far.

Could anyone please help us in getting these patches reviewed, and
(hopefully) accepted into webkit trunk?

Thank you,
Gergely
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Media Server Development

2013-01-31 Thread Kiran K
Thanks I will try webkit-help
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev