[webkit-dev] Common build system (was Re: WebKit Wishes)

Patrick Gansterer paroga at paroga.com
Thu Jan 31 00:49:57 PST 2013


Am 31.01.2013 um 09:25 schrieb Mark Rowe:
>> CMake was originally considered a non-starter for chromium since the
>> XCode and VS projects it produced didn't look or feel like native
>> projects. However, we've since switched to ninja for most things so
>> I'm less sure how important this is now. I've never been a huge fan of
>> the CMake syntax but I haven't used it enough to really have an
>> informed opinion.
> Generating well-structured Xcode projects is still something that is important for any meta build system that we would consider adopting for the Mac. It would be substantially more challenging for us to support an alternative system for building our production builds. If there are substantial advantages to using ninja for engineering builds then we may wish to support both to get the best behavior in each environment.
> The non-natively structured Xcode projects is one thing that turned me off CMake when I looked at it in the past. I’m not sure if this has improved since then. If not, then I don’t think CMake is worth spending much time on.

If you want to commit the generated projects CMake isn't an option anyway, since it uses absolute paths and also requires a cmake binary on the machine used for compiling (to support all CMake features across all generators). This tight integration is usually a big win, since the CMakeLists.txt files are part of the build system they can be changed directly in the IDE and update the project without invoking external tools.

Only for my personal interest: What do you mean exactly with non-natively structured Xcode projects? CMake aims to support a native IDE feel as far as possible. Would be great if you explain that to me (off-list) to get CMake improved for XCode?

>> Regarding "(b) The generated project invokes only tools that are part
>> of the default Mac OS X install": invoking tools that are checked into
>> the WK repo is also possible, right, since we invoke scripts now? So,
>> hypothetically, could we check in a copy of the ninja binary and build
>> with that?
> Checking in binaries isn’t an option for us, and isn’t a particularly scalable approach anyway given the number of platforms that WebKit can build on. If we require an external tool as a dependency to build WebKit from source then we’d need to check in the source for the tool and build it prior to building WebKit proper. This obviously introduces more complexity so it would be preferable to keep the dependencies to a minimum.

Maybe you can check in the ninja source and compile it during build. It only requires python (and hopefully installed build tools) to get built.

-- Patrick

More information about the webkit-dev mailing list