[webkit-dev] Peripheral ports (was Re: WebKit Wishes)
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))
(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))
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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
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
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)
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)
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)
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
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))
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)
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
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)
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
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)
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)
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)
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)
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)
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)
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)
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)
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
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))
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))
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))
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))
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))
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))
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))
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))
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))
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))
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))
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))
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))
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
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
Thanks I will try webkit-help ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
