Am 31.01.2013 um 21:07 schrieb Dirk Pranke: > On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima > <hugo.l...@openbossa.org> wrote: >> On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote: >>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke <dpra...@chromium.org> wrote: >>>> On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo <fpi...@apple.com> wrote: >>>>> Thanks for sharing this. >>>>> >>>>> On Jan 30, 2013, at 1:28 PM, Eric Seidel <e...@webkit.org> wrote: >>>>> >>>>> I wish we only had one build system (it were easy to add/remove/move >>>>> files). >>>>> >>>>> I believe changes like http://trac.webkit.org/changeset/74849 are an >>>>> unhealthy sign for the project. Adam is not the only person who has >>>>> chosen >>>>> to empty files instead of removing them. The pain of updating 8 build >>>>> system is so great, we jump through hoops to avoid it. Which means it >>>>> took >>>>> us months to move JavaScriptCore/wtf to WTF, and will take us years to >>>>> kill >>>>> WebCore/platform. >>>>> >>>>> >>>>> +1 >>>>> >>>>> This is a hard problem. It is a problem worth solving. >>>>> >>>>> Do you have more thoughts on this, particularly since you know quite well >>>>> how both Xcode and gyp work? >>>>> >>>>> I suspect this is one of those things that it would be hard to achieve >>>>> consensus on since there are so many stakeholders. But it may be >>>>> fruitful >>>>> to have a "what if" discussion about what this might look like. >>>> >>>> I think we can solve this problem if we agree that we want to. I think >>>> we haven't in the past mostly because we couldn't reach a consensus >>>> that it was worth solving enough to really try. >>>> >>>> I would love to see this fixed and would be glad to work on it. I >>>> think we should at least pursue this far enough to fully understand >>>> what our options are and what the costs and tradeoffs might be; does >>>> anyone disagree, and is anyone else willing to help pitch in? >>>> >>>> I think there are several possible ways we could solve this. One would >>>> be to switch to a common meta-build system. My understanding is that >>>> Apple's internal production build processes impose certain constraints >>>> here that I don't fully understand, but I know we've discussed the >>>> possibility of checking in generated project files as a workaround. >>>> Maybe there are other options as well to those constraints? I would >>>> love to discuss this further w/ someone from Apple ... >>> >>> It's far simplest for us if: >>> (a) There is an Xcode project (or a Makefile) that builds the Mac port >>> checked in to source control. (b) The generated project invokes only tools >>> that are part of the default Mac OS X install. >>> >>> It may not be completely impossible to violate these requirements but it >>> will require a lot of bureaucracy. >>>> (Also, just to get this out of the way, I don't think gyp needs to be >>>> the solution). >>>> >>>> Another alternative would be to write a script that did support at >>>> least the common use cases (add/move/delete files). There have been >>>> attempts in the past, but they have foundered on at least some >>>> perceived skepticism over how well this would work w/ XCode. That >>>> said, I don't think we've really pushed this to see. At some point >>>> this script might turn into a meta-meta-build system, which might be >>>> silly but also be the shortest path to the finish line. >>>> >>>> I suggest if there is interest in this we can start a new thread to >>>> discuss further ... >>> >>> My preference would be to use a common meta-build system with a comfortably >>> human-readable and human-editable syntax, and checked in generated project >>> files for those ports that need them. >>> >>> I think a key to making this work is to get Chromium and the Apple Mac port >>> onto a common build system, which will probably require both Google and >>> Apple ponying up at least one person to work on this project for a >>> reasonable period of time. >>> >>> I think the plausible meta-build-systems to use would be CMake and Gyp, but >>> in both cases it may be necessary to modify them to work well for everyone. >>> >>> I'd also like to add that I think a key related issue to common build system >>> is common feature configuration. The many different ways ports control >>> their feature flags is super confusing. I've long wanted to implement >>> common configuration management, but have not had time. >> >> I have a patch trying to solve this issue for CMake based ports[1], the patch >> still on going, but even a change affecting just 2-3 ports using the same >> build >> system is a bit hard to get a consensus, so you can imagine how hard will be >> to get a consensus over all WebKit ports. >> >> [1] https://bugs.webkit.org/show_bug.cgi?id=103162 >> > > This is slightly off-topic, but I had thought that no one was actually > using CMake; maybe I was mistaken and just none of the ports that > build on webkit.org are? It looks like Blackberry and maybe a WinCE > port uses CMake? Anyone else?
EFL uses CMake too. 4 EFL bots @ http://build.webkit.org 1 WinCE bot @ http://build.webkit.org 1 EFL bot as EWS -- Patrick _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev