[webkit-dev] Buildsystem cleanup

[Patrick Gansterer]

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?

The main idea in CMake is, that it does not know anything about Visual Studio sheets. This is required to use other generators as well (e.g. a -G Ninja). What you usually do with VS property sheets is done with CMake variables, where you store your compiler, linker or whatever flags.

> -How does CMake handle different build targets. Would I have to open up different project files per configuration?

In the default configuration CMake has 4 configurations: Debug, Release, MinSizeRelease and RelWithDebInfo. This allows in 99% direct production builds out of Visual Studio. Makefile generators (including Ninja) do not have this configuration and instead expect a -DCMAKE_BUILD_TYPE=<config> when running CMake. If you need additional configurations (e.g. the current Production configs) the CMake-way is to do this with an additional CMake variable defined via command line. So if you want a "production build" you just add a "-DBUILD_FOR_PRODUCTION=ON" to the initial call to cmake. Then you can do stuff like "if (BUILDFOR_PRODUCTION) list(APPEND LINNKER_FLAGS "...") endif ()" to get the job done.

> -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.

Importent is that you do not change the VS files any more. Only the CMake files should be changed then. CMake adds an additional project into the Visual Studio solution (ZERO_CHECK), which detects modified CMake files and runs cmake if something has changed. Since adding/removing a source files results in a change of the CMake file everything is done automatically.
build-wekit has already support for CMake, so you only need to remove the VS code. :-)

> 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?. 

You can do this in VS as well: You only need to open the CMakeLists.txt in Visual Studio and add i there. Pressing the build button then generates new VS project, as mentioned before.

> -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.

"-G" does the job. You can also use Makefile based generators with no extra work. IMHO it would be great to use "-G Ninja" an the buildbots, since it has a much better output when you only see the command line (and it's faster).

> 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.

Many thanks. Please let me know if you see additional "problems" so we can address them as soon as possible.

> 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.

Please let me know when I can help somewhere.

> 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.

IMHO we can enforce new ports to use CMake already. Does anybody know if it's possible for the Qt port to switch to CMake? I know that QtWebKit is part of the Qt source distribution, which does not require CMake.
Maybe somebody can tell me if the following would work for Qt:
Use the CMake builds as e.g. EFL does at the moment and add an additional target for auto-generation of the qmake files. This qmake files then only have a list of header and source files, since code-generators (e.g. for IDL) are run by CMake. 


Am 11.04.2013 um 00:39 schrieb Brent Fulgham:

> On Apr 10, 2013, at 3:30 PM, Roger Fong <roger_fong at apple.com> wrote:
> 
>> 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 think the enable/disable stuff we use for conditionally building WinCairo versus stock Apple would go away; ale generates project files with only the relevant items per build.

Yes. WinCairo will become a complete independent port in CMake, but shares files with the WindowsApple and WinCE port.

>> ... 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.
> 
> I can help with this now.

If i get an OK, that it can work for Apple internal, I'd like to start with switching over the WinCairo port in a first step, since it is 100% open.
I also like to ignore possible reuse of source lists as mentioned at webkit.org/b/76418. E.g. it should be possible to add a UseCURL.cmake in a next step, which can be included by ports who use CURL as network backend, so the files and libraries need to be maintained only once. I'd like to do this in a second "cleanup" step, since it's easier, when we see the requirements to CMake in working files.

>> 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.
> 
> Agreed!
> 
> Patrick, can you expound a little on the abilities cmake apparently has for performing shell operations? I think you suggested at one point that some of the. Things we currently do with BASH and DOS shell scripts could be done by cmake. Can you elaborate on what kind of things?

If you look at the current files for WinCE (or the CMake files for WinApple at webkit.org/b/72816) you see that it uses no cygwin stuff at all. All code-generators are in the main project (e.g. WebCore, WebKit). E.g. it's possible to click "Compile" on an IDL file, which invokes the code generator only for that file. Same applies to all other generated files too.


Am 11.04.2013 um 01:07 schrieb Martin Robinson:

> On Wed, Apr 10, 2013 at 3:30 PM, Roger Fong <roger_fong at apple.com> wrote:
>> 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.
> 
> We're going to try it out for WebKitGTK+ and that really just leaves
> QtWebKit on qmake [1]. Perhaps someday WebKit will only have two build
> systems. :)

Please let me know if I can help you somewhere. I can not review the resulting patch (since I'm not a reviewer (jet)), but it would be great if you can CC on relevant patches.

> 1. There's also the Wx port, but they don't seem very interested in
> switching and it seems the build system is very low maintenance.

There is still a patch at webkit.org/b/73100 for adding CMake files for Wx.

-- Patrick