Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
Hi Darin, On Nov 2, 2011, at 4:42 PM, Darin Adler wrote: On Nov 2, 2011, at 4:09 PM, Mark Rowe wrote: There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. Step (2) here involves coming up with a good solution for export control in both the WTF and platform cases. Today we use an explicit .exp file for JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple Windows WebKit port. So there might be a necessary first step of moving to a different export approach. And I know someone has been working on that. If you guys want to go the route of finishing up the export macros work, let me know and I'll see what I can do. I probably can't devote a lot of time to it for the next week or two, but I'd like to see this fixed regardless of if it's used to move forward the WTF split, obviously, so I can put a higher priority on it if I know there are reviewers waiting to land things. :) FWIW, I did distinguish between JS and WTF symbol export macros in the work I've been doing, so the macros approach will support the split as-is. Thanks, Kevin -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Nov 4, 2011, at 8:48 AM, Kevin Ollivier wrote: Step (2) here involves coming up with a good solution for export control in both the WTF and platform cases. Today we use an explicit .exp file for JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple Windows WebKit port. So there might be a necessary first step of moving to a different export approach. And I know someone has been working on that. If you guys want to go the route of finishing up the export macros work, let me know and I'll see what I can do. I probably can't devote a lot of time to it for the next week or two, but I'd like to see this fixed regardless of if it's used to move forward the WTF split, obviously, so I can put a higher priority on it if I know there are reviewers waiting to land things. :) FWIW, I did distinguish between JS and WTF symbol export macros in the work I've been doing, so the macros approach will support the split as-is. If WTF is to be a static library, there's no need to change anything in the .def file on Windows. .def files apply only to DLLs. FWIW, WTF is already a static library in Apple's Windows port, just self-contained inside the JavaScriptCore project. See: http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/JavaScriptCore.vcproj/WTF/WTF.vcproj -steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On 2011-11-04, at 10:57, Kevin Ollivier wrote: Hi Steve, On Nov 4, 2011, at 9:12 AM, Steve Falkenburg wrote: On Nov 4, 2011, at 8:48 AM, Kevin Ollivier wrote: Step (2) here involves coming up with a good solution for export control in both the WTF and platform cases. Today we use an explicit .exp file for JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple Windows WebKit port. So there might be a necessary first step of moving to a different export approach. And I know someone has been working on that. If you guys want to go the route of finishing up the export macros work, let me know and I'll see what I can do. I probably can't devote a lot of time to it for the next week or two, but I'd like to see this fixed regardless of if it's used to move forward the WTF split, obviously, so I can put a higher priority on it if I know there are reviewers waiting to land things. :) FWIW, I did distinguish between JS and WTF symbol export macros in the work I've been doing, so the macros approach will support the split as-is. If WTF is to be a static library, there's no need to change anything in the .def file on Windows. .def files apply only to DLLs. Yes, I know, just saying I'd be willing to help if they wanted to go the DLL route. Making it static would make life easier for me also by allowing us to remove the need for WTF symbol exports entirely, of course, so either way is a plus for me. WTF being a static library doesn't change anything with respect to exports. It will still only be linked by a single dynamic library, and that library will be expected to export the necessary symbols for other clients. Doing otherwise would cause problems due to multiple instances of WTF's data being created (e.g., separate FastMalloc heaps for each library that linked directly to WTF). - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
Hi Mark, On Nov 4, 2011, at 10:59 AM, Mark Rowe wrote: On 2011-11-04, at 10:57, Kevin Ollivier wrote: Hi Steve, On Nov 4, 2011, at 9:12 AM, Steve Falkenburg wrote: On Nov 4, 2011, at 8:48 AM, Kevin Ollivier wrote: Step (2) here involves coming up with a good solution for export control in both the WTF and platform cases. Today we use an explicit .exp file for JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple Windows WebKit port. So there might be a necessary first step of moving to a different export approach. And I know someone has been working on that. If you guys want to go the route of finishing up the export macros work, let me know and I'll see what I can do. I probably can't devote a lot of time to it for the next week or two, but I'd like to see this fixed regardless of if it's used to move forward the WTF split, obviously, so I can put a higher priority on it if I know there are reviewers waiting to land things. :) FWIW, I did distinguish between JS and WTF symbol export macros in the work I've been doing, so the macros approach will support the split as-is. If WTF is to be a static library, there's no need to change anything in the .def file on Windows. .def files apply only to DLLs. Yes, I know, just saying I'd be willing to help if they wanted to go the DLL route. Making it static would make life easier for me also by allowing us to remove the need for WTF symbol exports entirely, of course, so either way is a plus for me. WTF being a static library doesn't change anything with respect to exports. It will still only be linked by a single dynamic library, and that library will be expected to export the necessary symbols for other clients. Doing otherwise would cause problems due to multiple instances of WTF's data being created (e.g., separate FastMalloc heaps for each library that linked directly to WTF). So I'm assuming that dynamic library would be JSCore, then? Is the idea basically just to have a clean separation between WTF and JSCore build projects? Thanks, Kevin - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Fri, Nov 4, 2011 at 11:12 AM, Kevin Ollivier kev...@theolliviers.com wrote: So I'm assuming that dynamic library would be JSCore, then? Is the idea basically just to have a clean separation between WTF and JSCore build projects? Yes. Conceptually, WTF is a separate layer from JavaScriptCore. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
Mark, I've created a stub WTF library at http://trac.webkit.org/browser/trunk/Source/WTF Would you be willing to create an appropriate xcodeproj file that builds Stub.h and Stub.cpp (and integrates with whatever magic is needed internally at Apple)? I'm also happy to attempt webkit.org side of that change if you'd prefer, but I suspect you know better what the contrains are. Thanks, Adam On Wed, Nov 2, 2011 at 4:47 PM, Adam Barth aba...@webkit.org wrote: On Wed, Nov 2, 2011 at 4:35 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 16:32, Adam Barth wrote: On Wed, Nov 2, 2011 at 4:09 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 13:23, Adam Barth wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. Yes. These are the goals. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. I don't see any benefit or need to move existing Xcode projects as part of this process. Can you expand on why you included this in your proposal? Based on our previous discussions, I was unsure how difficult (3) was on your end. If we can make (a) and (b) happen in the near term without moving xcodeproj files around, that would make me a happy camper. The code moving and the new Xcode project is relatively easy. I'm not sure what will be involved in updating all of the other build systems though. I'm happy to coordinate that part of the effort. I'm not entirely clear on what we'll need to do to tackle c). My current feeling is that it will mainly involve reshuffling of Apple's build processes rather than any significant changes to WebKit. Maybe we should aim to do (a) first, then (b), and then work on (c) once we've figured out what needs to happen on Apple's end? My recollection of the situation with WebCore/platform is that there are a number of existing layering violations in some ports. Given the approach outlined above I suspect they may need to be addressed before we can start making progress on b). Yes. Fixing these issues is going to be a fair amount of work. Perhaps it would make sense to create a stub Platform project for now, which will let us move code from WebCore/platform into Platform as we clean up the dependencies. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On 2011-11-04, at 11:56, Adam Barth wrote: Mark, I've created a stub WTF library at http://trac.webkit.org/browser/trunk/Source/WTF Would you be willing to create an appropriate xcodeproj file that builds Stub.h and Stub.cpp (and integrates with whatever magic is needed internally at Apple)? I'm also happy to attempt webkit.org side of that change if you'd prefer, but I suspect you know better what the contrains are. Yup, it's on my list. - Mark On Wed, Nov 2, 2011 at 4:47 PM, Adam Barth aba...@webkit.org wrote: On Wed, Nov 2, 2011 at 4:35 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 16:32, Adam Barth wrote: On Wed, Nov 2, 2011 at 4:09 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 13:23, Adam Barth wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. Yes. These are the goals. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. I don't see any benefit or need to move existing Xcode projects as part of this process. Can you expand on why you included this in your proposal? Based on our previous discussions, I was unsure how difficult (3) was on your end. If we can make (a) and (b) happen in the near term without moving xcodeproj files around, that would make me a happy camper. The code moving and the new Xcode project is relatively easy. I'm not sure what will be involved in updating all of the other build systems though. I'm happy to coordinate that part of the effort. I'm not entirely clear on what we'll need to do to tackle c). My current feeling is that it will mainly involve reshuffling of Apple's build processes rather than any significant changes to WebKit. Maybe we should aim to do (a) first, then (b), and then work on (c) once we've figured out what needs to happen on Apple's end? My recollection of the situation with WebCore/platform is that there are a number of existing layering violations in some ports. Given the approach outlined above I suspect they may need to be addressed before we can start making progress on b). Yes. Fixing these issues is going to be a fair amount of work. Perhaps it would make sense to create a stub Platform project for now, which will let us move code from WebCore/platform into Platform as we clean up the dependencies. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Fri, Nov 4, 2011 at 12:04 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-04, at 11:56, Adam Barth wrote: I've created a stub WTF library at http://trac.webkit.org/browser/trunk/Source/WTF Would you be willing to create an appropriate xcodeproj file that builds Stub.h and Stub.cpp (and integrates with whatever magic is needed internally at Apple)? I'm also happy to attempt webkit.org side of that change if you'd prefer, but I suspect you know better what the contrains are. Yup, it's on my list. Thanks! Adam On Wed, Nov 2, 2011 at 4:47 PM, Adam Barth aba...@webkit.org wrote: On Wed, Nov 2, 2011 at 4:35 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 16:32, Adam Barth wrote: On Wed, Nov 2, 2011 at 4:09 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 13:23, Adam Barth wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. Yes. These are the goals. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. I don't see any benefit or need to move existing Xcode projects as part of this process. Can you expand on why you included this in your proposal? Based on our previous discussions, I was unsure how difficult (3) was on your end. If we can make (a) and (b) happen in the near term without moving xcodeproj files around, that would make me a happy camper. The code moving and the new Xcode project is relatively easy. I'm not sure what will be involved in updating all of the other build systems though. I'm happy to coordinate that part of the effort. I'm not entirely clear on what we'll need to do to tackle c). My current feeling is that it will mainly involve reshuffling of Apple's build processes rather than any significant changes to WebKit. Maybe we should aim to do (a) first, then (b), and then work on (c) once we've figured out what needs to happen on Apple's end? My recollection of the situation with WebCore/platform is that there are a number of existing layering violations in some ports. Given the approach outlined above I suspect they may need to be addressed before we can start making progress on b). Yes. Fixing these issues is going to be a fair amount of work. Perhaps it would make sense to create a stub Platform project for now, which will let us move code from WebCore/platform into Platform as we clean up the dependencies. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Moving WTF out of JavaScriptCore (revisited)
As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Wed, Nov 2, 2011 at 4:23 PM, Adam Barth aba...@webkit.org wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) That'd be most excellent. ChangeLog would be cleanly split out as a nice side effect to doing this, as well as w/ WTF vs. JavaScriptCore. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On 2011-11-02, at 13:23, Adam Barth wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. I don't see any benefit or need to move existing Xcode projects as part of this process. Can you expand on why you included this in your proposal? I'm not entirely clear on what we'll need to do to tackle c). My current feeling is that it will mainly involve reshuffling of Apple's build processes rather than any significant changes to WebKit. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Wed, Nov 2, 2011 at 4:09 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 13:23, Adam Barth wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. Yes. These are the goals. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. I don't see any benefit or need to move existing Xcode projects as part of this process. Can you expand on why you included this in your proposal? Based on our previous discussions, I was unsure how difficult (3) was on your end. If we can make (a) and (b) happen in the near term without moving xcodeproj files around, that would make me a happy camper. I'm not entirely clear on what we'll need to do to tackle c). My current feeling is that it will mainly involve reshuffling of Apple's build processes rather than any significant changes to WebKit. Maybe we should aim to do (a) first, then (b), and then work on (c) once we've figured out what needs to happen on Apple's end? Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On 2011-11-02, at 16:32, Adam Barth wrote: On Wed, Nov 2, 2011 at 4:09 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 13:23, Adam Barth wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. Yes. These are the goals. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. I don't see any benefit or need to move existing Xcode projects as part of this process. Can you expand on why you included this in your proposal? Based on our previous discussions, I was unsure how difficult (3) was on your end. If we can make (a) and (b) happen in the near term without moving xcodeproj files around, that would make me a happy camper. The code moving and the new Xcode project is relatively easy. I'm not sure what will be involved in updating all of the other build systems though. I'm not entirely clear on what we'll need to do to tackle c). My current feeling is that it will mainly involve reshuffling of Apple's build processes rather than any significant changes to WebKit. Maybe we should aim to do (a) first, then (b), and then work on (c) once we've figured out what needs to happen on Apple's end? My recollection of the situation with WebCore/platform is that there are a number of existing layering violations in some ports. Given the approach outlined above I suspect they may need to be addressed before we can start making progress on b). - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Nov 2, 2011, at 4:09 PM, Mark Rowe wrote: There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. Step (2) here involves coming up with a good solution for export control in both the WTF and platform cases. Today we use an explicit .exp file for JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple Windows WebKit port. So there might be a necessary first step of moving to a different export approach. And I know someone has been working on that. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Nov 2, 2011, at 4:42 PM, Darin Adler wrote: Step (2) here involves coming up with a good solution for export control in both the WTF and platform cases. Today we use an explicit .exp file for JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple Windows WebKit port. So there might be a necessary first step of moving to a different export approach. And I know someone has been working on that. Or maybe these will be statically linked libraries? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On 2011-11-02, at 16:42, Darin Adler wrote: On Nov 2, 2011, at 4:09 PM, Mark Rowe wrote: There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. Step (2) here involves coming up with a good solution for export control in both the WTF and platform cases. Today we use an explicit .exp file for JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple Windows WebKit port. So there might be a necessary first step of moving to a different export approach. And I know someone has been working on that. My current line of thinking was that WTF would build as a static library. JavaScriptCore's existing mechanism for exporting symbols should be sufficient to ensure that the necessary WTF symbols are still exposed. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Wed, Nov 2, 2011 at 4:35 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 16:32, Adam Barth wrote: On Wed, Nov 2, 2011 at 4:09 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 13:23, Adam Barth wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. Yes. These are the goals. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. I don't see any benefit or need to move existing Xcode projects as part of this process. Can you expand on why you included this in your proposal? Based on our previous discussions, I was unsure how difficult (3) was on your end. If we can make (a) and (b) happen in the near term without moving xcodeproj files around, that would make me a happy camper. The code moving and the new Xcode project is relatively easy. I'm not sure what will be involved in updating all of the other build systems though. I'm happy to coordinate that part of the effort. I'm not entirely clear on what we'll need to do to tackle c). My current feeling is that it will mainly involve reshuffling of Apple's build processes rather than any significant changes to WebKit. Maybe we should aim to do (a) first, then (b), and then work on (c) once we've figured out what needs to happen on Apple's end? My recollection of the situation with WebCore/platform is that there are a number of existing layering violations in some ports. Given the approach outlined above I suspect they may need to be addressed before we can start making progress on b). Yes. Fixing these issues is going to be a fair amount of work. Perhaps it would make sense to create a stub Platform project for now, which will let us move code from WebCore/platform into Platform as we clean up the dependencies. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
