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
