On Thu, Jan 31, 2013 at 12:10 PM, Patrick Gansterer <par...@paroga.com> wrote: > > 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 >
Ah, I thought EFL was using Autotools. Thanks for the correction. -- Dirk _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev