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

[Hajime Morrita]

In my understanding, it doesn't matter whether Apple Mac port supports
ninja or not. We could use GNU make if some meta-build system is adopted
because Mac OS has it installed. The problem here is that the neither CMake
and GYP isn't easy to adopt for reasons discussed in this thread.

My personal feeling is that we could build a simple meta build system which
specifically targetsMac WebKit and XCode.

It could be just a little more than a templating system which generates the
list of files plus their UUIDs. The tool doesn't need to be so general like
CMake/GYP. Many tricky configuration things could be in the hard-coded
boilerplate. It could just focus on generating file list and UUIDs. It's
something like project.pbxproj.in and its preprocessor.

It won't be a direct step toward the unified build system. But we'll figure
out the next step once the build is represented by a simple plain text.

--
morrita


On Thu, Jan 31, 2013 at 5:49 PM, Patrick Gansterer <paroga at paroga.com>wrote:

> Hi,
>
> 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
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130131/96d8e2ee/attachment-0001.html>