Re: [webkit-dev] Tips to build faster on Mac?
Thanks everyone! I had a chance to try plain "make d -C Source/WebCore" today and it's a lot faster. Small changes build under a minute, so this is very helpful! On Fri, Mar 16, 2018 at 12:40 PM, Maciej Stachowiak <m...@apple.com> wrote: > > You can also just cd to the WebCore directory and type make. > > On Mar 16, 2018, at 3:24 PM, youenn fablet <youe...@gmail.com> wrote: > > If you have a full build and made changes to WebCore, you might only need > to recompile WebCore. With make for instance, one can do: > make d -C Source/WebCore > > Y > > On Fri, Mar 16, 2018 at 6:55 AM Danyao Wang <dan...@chromium.org> wrote: > >> Thanks Brian for the Xcode UI tip! So far I've always used build-webkit. >> I didn't realize there could be a difference. >> >> On Thu, Mar 15, 2018 at 6:01 PM, Brian Burg <bb...@apple.com> wrote: >> >>> >>> >>> > On Mar 15, 2018, at 1:58 PM, Danyao Wang <dan...@chromium.org> wrote: >>> > >>> > Hi, >>> > >>> > Being new to WebKit development (and also switching from Linux to >>> Mac), I find my workflow relatively clumsy. Building on a fresh checkout >>> usually takes me 20+ minutes even on my 12-core Mac Pro. Fastest >>> incremental builds are ~2 minutes. This adds a lot to the develop / test / >>> debug cycle. >>> >>> These build times seem normal. WebKit is a big project, and we don’t use >>> CMake/ninja by default when building for Cocoa ports. >>> >>> Are you building via build-webkit on the command line? In my experience, >>> incremental builds are faster via Xcode’s UI. >>> >>> > I heard the good folks from Igalia working on the GTK port use icecc. >>> Has anyone used this on Mac? Any other productivity tips? >>> > >>> > Thanks! >>> > Danyao >>> > ___ >>> > webkit-dev mailing list >>> > webkit-dev@lists.webkit.org >>> > https://lists.webkit.org/mailman/listinfo/webkit-dev >>> >>> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Tips to build faster on Mac?
Thanks Brian for the Xcode UI tip! So far I've always used build-webkit. I didn't realize there could be a difference. On Thu, Mar 15, 2018 at 6:01 PM, Brian Burg <bb...@apple.com> wrote: > > > > On Mar 15, 2018, at 1:58 PM, Danyao Wang <dan...@chromium.org> wrote: > > > > Hi, > > > > Being new to WebKit development (and also switching from Linux to Mac), > I find my workflow relatively clumsy. Building on a fresh checkout usually > takes me 20+ minutes even on my 12-core Mac Pro. Fastest incremental builds > are ~2 minutes. This adds a lot to the develop / test / debug cycle. > > These build times seem normal. WebKit is a big project, and we don’t use > CMake/ninja by default when building for Cocoa ports. > > Are you building via build-webkit on the command line? In my experience, > incremental builds are faster via Xcode’s UI. > > > I heard the good folks from Igalia working on the GTK port use icecc. > Has anyone used this on Mac? Any other productivity tips? > > > > Thanks! > > Danyao > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit
Hi Philip, Ali and I would be willing to help this wherever we can. It seems to us that there may be a few different classes of tests that require varying degree of effort to migrate. Do you have any estimates on how many tests fall into each category, maybe based on your analysis of Blink LayoutTests? 1. braindead to migrate - 1a) ref tests not using window.internals - 1b) tests using internals API that have trivial equivalent in testharness 2. tests using non-trivial internals API so require some domain expertise in the functionality under test - 2a) priority features: maybe active development so more likely to diverge in the near future? - 2b) long tail 3. tests that can't be migrated to WPT - 3a) tests that explicit use layerTreeAsText (tests in the compositing layer) - 3b) tests that dump render object tree (testing browser internals) Thanks, Danyao On Wed, Nov 15, 2017 at 5:02 AM, Philip Jägenstedt <foo...@chromium.org> wrote: > Hello webkit-dev! (ecosystem-infra in Bcc) > > TPAC was last week, and there was much talk about web-platform-tests. Some > notes are at https://lists.w3.org/Archives/Public/public-test- > infra/2017OctDec/thread.html and in particular https://www.w3.org/ > 2017/11/07-testing-minutes.html. > > In Blink, we're thinking seriously about what it'd take to upstream large > parts of LayoutTests into web-platform-tests, and we've realized that there > are some risks here, beyond just making sure the tests are good and per > spec. Specifically, one bad outcome would be if Blink successfully > upstreamed thousands of tests that are also in WebKit, which then begin to > diverge in small and large ways. That'd leave WebKit with more duplication > between its own tests and web-platform-tests than any other engine, and a > headache that grows over time. > > So, I think this would require close cooperation with the WebKit project. > Some different ways this might happen: > >1. A Blink developer and WebKit developer work together at the same >time to move their common tests in some area into web-platform-tests, each >removing identical tests that were upstreamed by the other and >consolidating what remains. >2. A Blink developer works to first upstream tests from WebKit (using >WebKit's coming export mechanism), waits for it to be imported into Blink, >and then removes the tests from Blink. >3. The reverse situation. > > > Are there already some areas where the first approach might be doable, > where the Blink and WebKit folks already know each other and are eager to > do this? Is LayoutTests/css3/flexbox/ by any chance such a case? > > I realize it's hard to judge these approaches in the abstract, but am > curious to hear any enthusiasm or concerns about it. > > Thanks! > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
