[webkit-dev] Moving WTF out of JavaScriptCore (revisited)

[Adam Barth]

On Wed, Nov 2, 2011 at 4:35 PM, Mark Rowe <mrowe at apple.com> wrote:
> On 2011-11-02, at 16:32, Adam Barth wrote:
>> On Wed, Nov 2, 2011 at 4:09 PM, Mark Rowe <mrowe at 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