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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
