[webkit-dev] Buildsystem cleanup
roger_fong at apple.com
Mon Jul 15 13:42:18 PDT 2013
We haven’t looked at it, but we’ve decided we are interested in making it work for us.
However, we will still need to keep the VS2010 project files in our tree for some undetermined amount of time. If you want to start adding a cmake support windows support for the AppleWin port to the tree, that’d be great! Unfortunately, we’ll have to wait for some time before fully adopting cmake into our system.
Feel free to ask Brent and me for help at any point though!
On Jul 12, 2013, at 5:07 AM, Patrick Gansterer <paroga at paroga.com> wrote:
> Hi Roger,
> did you have some time to look at my example in the meantime?
> -- Patrick
> Am 11.04.2013 um 00:30 schrieb Roger Fong:
>> Hi Patrick,
>> A few questions I have about the CMake system, being someone who's never used it before.
>> -I would like to keep all of the unified properties settings that the VS2010 property sheets hierarchy provided.
>> Can we still maintain that through CMake easily?
>> -How does CMake handle different build targets. Would I have to open up different project files per configuration?
>> -If I'm understanding things correctly the main differences with using CMake would be:
>> 1. If a project configuration is changed run CMake / I guess whenever you update the source as well (just to be safe).
>> We would want to change any build scripts to use CMake: perhaps build-webkit is the really the only one we have to worry about in the OpenSource tree.
>> 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on.
>> Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we would maintain that would hook into the generated projects?.
>> -I'm assuming there's a CMake flag for specifying which version of visual studio to generate project files for?
>> Our opensource bots run VS2005 and our internal run VS2010 currently, and seeing as we're not ready to use only VS2010 yet we would need to be able to specify which.
>> If my above concerns can be resolved and the example you posted works fine for us (I'll try to take a look at it soon), it's probably okay to start checking in stuff to get ready for the move to CMake. I don't think we really have the resources to get things hooked up on our end in the immediate future, but perhaps in the coming months.
>> Also if we do end up switching over I would highly push for all other ports besides Mac to adopt CMake and require any new ports to use it as well.
>> On Apr 9, 2013, at 9:34 AM, Patrick Gansterer <paroga at paroga.com> wrote:
>>> On Mon, 08 Apr 2013 18:10:29 -0700, Mark Rowe wrote:
>>>> On 2013-04-08, at 17:45, Patrick Gansterer <paroga at paroga.com> wrote:
>>>> Sounds good.
>>> You can test it with the following steps. The helper directory contains then all "built" files.
>>> * Create a directory helper
>>> * Copy all files from Source/cmake to helper/cmake
>>> * Copy all files (including the support libraries) from WebKitLibraries to helper/WebKitLibraries
>>> * Create an independent directory and run the following commands in it:
>>> $ cmake path/to/WebKit/Source/WTF/wtf -DPORT=WinApple -DHELPER_DIR=path/to/helper
>>> $ cmake --build . --target package
>>> * You get a WTF.zip, which should be extracted in the directory helper
>>> * Create an additional independent directory and run the following commands in it:
>>> $ cmake --build . --target package
>>> I would be great if someone can verify that this solution will work for the internal builds at Apple.
>>> If I get positive feedback I'll can implement this for WebCore and WebKit too. Is there someone who will review my patches for this?
>>> Do you think it's possible to directly switch to CMake at Apple instead of upstreaming the VS2010 files? IHMO the whole work can be done in a few days, if someone at Apple is willing to work with me on it.
>>>  https://github.com/paroga/webkit
>>> -- Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev