Please guys, No need to speculate here on what I proposed at the session since Evan somehow left some details out and let me reinforce some points. For those who missed the session, please understand that what's Peter said isn't exactly what we agreed on.
Here's some data points: - No plan to generate qtmake or makefile.am or whatever else - No plan to force anyone to switch - No plan (for now) to get any automatic file list for the checkout (some build system do that) - No plan for any "template based" project generation - Making a new fully functional backend to gyp *is* involved. It's a big deal. There's no use in a 95% done build system. The rough proposal is: - De-chromify most .gyp and .gypi files currently living in webkit.org, split the files off as necessary in the process to untangle conditions. - With coordination with aroben, look at implementing a faithful copy of apple's win port, with a potential switch over *if it works out*. No guarantee. - Some people expressed interest into generating the file list to their build system and having the build system import the generated project files. That wouldn't be a complete backend implementation. Obviously, complete backend implementation at http://code.google.com/p/gyp are welcome as long as they have unit tests. What you can do *only if you want*: - Extract the file list of your port project into a single simple file and have your build system "import" this file. I'm not talking about pushing anyone's back and I have *no intention* to. So unless you want to actively submit patches towards the proposal, please let this thread die, it's an unproductive use of my time. I don't plan to do that in the very short term as I have other things on my plate, I'll definitely do this incrementally. M-A 2010/4/16 Peter Kasting <[email protected]> > On Fri, Apr 16, 2010 at 8:42 AM, Kevin Ollivier > <[email protected]>wrote: > >> Perhaps, but in any case, I think the first step there is for the Gyp >> developers to try implementing support and see how it goes. However, from >> that perspective, until Gyp has support for those formats, isn't a >> discussion about switching for other ports a bit premature on the WebKit >> side? i.e. that would be next steps for Gyp, not next steps for WebKit. I'd >> think Gyp would implement support for those formats and then come here and >> ask people to consider a switch. >> > > Which is basically what we're proposing here. > > PK > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -- M-A
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
