[webkit-dev] [webkit meeting notes] build systems

[Maciej Stachowiak]

On Apr 17, 2010, at 11:11 AM, Kevin Ollivier wrote:

>
> True, but I think the real problem that we're not addressing in this  
> discussion is that different ports have different sets of  
> requirements, meaning their own evaluation process would lead them  
> to choose different tools. If we want a 'one size fits all' build  
> system, the first step is getting each port to come together and  
> consolidate the requirements, and there will most likely need to be  
> some compromises involved as some ports may have to agree to move to  
> a tool that's not really as well suited for their project as the one  
> they're using now.

It's true that different ports have different requirements. So far,  
this has resulted in every port choosing a different build system.  
While in some ways this may be convenient for individual ports, it  
creates negative externalities for the project as a whole.

That being said, we're not trying to convert to one true build system  
right now, merely seeing if we can reduce the number by having more  
ports share a build system.

We're even considering changing the build system for Apple's ports (in  
fact the Apple Windows port may be one of the first experiments).
>
> For example, a primary reason tools like Gyp and Bakefile exist is  
> that for some people, lack of a 100% native IDE-based build system  
> is a deal breaker. For others, like myself, I want low maintenance,  
> completely cross-platform, highly automated and highly scriptable,  
> which are actually features the IDE projects don't fare very well  
> in. So one man's feature is another man's drawback.
>
> There are also factors besides features that are important as well.  
> I think it's also important to remember that from each port's  
> perspective, one potentially big factor in build system choice is  
> also making users comfortable with contributing. For GTK, for  
> example, that may mean that using autotools, the build system most  
> likely to be familiar to potential contributors, is in part a way of  
> making contributing a little less intimidating on a big project like  
> WebKit. Similar with qmake, XCode, etc. I think that a big part of  
> build system decision making is based not necessarily around  
> features, but around being in the developers' comfort zones. So my  
> gut impression is that it's going to be very difficult to find an  
> existing tool that solves all the issues like this for most / all  
> ports in a way that makes everyone happy.
>
> As the saying goes, sometimes the perfect is indeed the enemy of the  
> good. I personally think a quick and simple solution along the lines  
> of what Nikolas and I were talking about maybe the only short term  
> improvement that is viable. Everything else is looking more long- 
> term, and requires both a lot of effort and a lot of collaboration  
> among ports. To the point that, as a practical matter, I'm not sure  
> if the system would save more time than it would take to develop.  
> That's not to say such a system won't be developed, but absent some  
> sponsorship of the project or some highly motivated hackers, I don't  
> know how we plan on getting there.
>
> I just think this subject has come up numerous times, and each time  
> the discussion ended without any improvements being made, so I worry  
> that so long as we wait for the perfect system to come along, we're  
> not going to build the good system that can make life better today.

I would put that the other way around. Gyp exists today and knows how  
to generate an Xcode project. The templating solution that can  
generate an Xcode project while seeming less intrusive to Bakefile and  
Automake users is completely hypothetical. Anyone who wants to is  
welcome to try to code it, but my expectation going in is that it  
would evolve to be as complex as Gyp.

Regards,
Maciej


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100417/8868d6af/attachment.html>