[webkit-dev] Buildsystem cleanup

[Patrick Gansterer]

Am 09.04.2013 um 02:29 schrieb Mark Rowe:

> 
> On 2013-04-08, at 17:16, Patrick Gansterer <paroga at paroga.com> wrote:
> 
>> 
>> Am 09.04.2013 um 00:58 schrieb Mark Rowe:
>> 
>>> 
>>> On 2013-04-08, at 15:44, Patrick Gansterer <paroga at paroga.com> wrote:
>>> 
>>>> 
>>>> Am 08.04.2013 um 21:26 schrieb Roger Fong:
>>>> 
>>>>> Unfortunately this would cause a lot of complication in our internal build setup that we currently don’t really have the resources to deal with right now.
>>>> 
>>>> Please don't get me wrong, but I only get a "some internal problems" answer always. Can someone please give some more detailed answer on the internal requirements. I'm willing to do the work for the Windows ports, but I need more information. How is the Windows port built at Apple? Is it possible to switch it to a CMake generated project? 
>>> 
>>> The biggest complicating factor is that when each project builds it only has access to its own source, and the built products from earlier projects. This was mentioned the last time you suggested switching to CMake for the Windows build: <https://lists.webkit.org/pipermail/webkit-dev/2012-April/020291.html>.
>> 
>> I know the last thread, so please don't hurt me if I ask dumb questions, but how does it work at the moment? ;-)
>> What is the root directory of a checkout? E.g. if I checkout only Source/JavaScriptCore how can I access the vsprops files from WebKitLibraries/win?
> 
> WebKitLibraries/win/tools is treated as its own project. It is built first so that the other WebKit projects can use the files that it installs. You can see a Makefile at WebKitLibraries/win/tools/WinTools.make that does the installation.

So having an additional top level directory with all shares CMake files is possible? How are the ENABLE_* feature defines  handled? Are they part of this files too?

>> Is there a checkout of this "global" files for the individual targets too?
> 
> No.

But they are "installed" via a previous build, so mainly the same. ;-)

>> If there is a checkout of the whole tree for every target, how do you make sure that the files from the previous build are use (and not from the checkout)?
> 
> Only a subset of the tree is available. For instance, when preparing to build JavaScriptCore the relevant source is fetched using “svn export https://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore”. The resulting directory is then provided to the build machine.

Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can have a look at it then to check if I understand the concept correctly before I move on to WebCore + WebKit?

>> Beside this, is there a general problem with CMake for the Windows port? For the Mac port there is the problem, that CMake is not an executable provided by the system (maybe i can some time...). Since many other tools are require separate installation  on Windows anyway there should be no problem in installing CMake too?
> 
> Making the CMake executable available shouldn’t be a problem.
> 
> Do the projects generated by CMake suffer from the same problem with absolute paths as CMake’s Xcode projects? I’m not sure whether that would be a problem for us on Windows, but it’s good to understand any limitations ahead of time.

What is the concrete "problem" with the absolute paths? It's true that you can't copy a generated vcproj to an other location, but that shouldn't be required when you have installed CMake on that machine. And since the CMake executable is required by the generated build files (in the background for platform abstraction) it makes not much sense in a CMake workflow anyway. You usually just run "cd build_dir && cmake path/to/source && cmake --build ." and get all your files built.

-- Patrick