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
