PTAL
I changed the public_dep for the unittests to just require the headers and not the full platform/heap. This seems to fix linking on windows. Delta: https://chromium-review.googlesource.com/c/chromium/src/+/828734/1..3
To view, visit change 828734. To unsubscribe, or for help writing mail filters, visit settings.
LGTM
Patch set 3:Code-Review +1
And now the chromeos builder is unhappy, see
https://build.chromium.org/deprecated/tryserver.chromium.chromiumos/builders/chromeos-daisy-rel/builds/23331/steps/compile%20(with%20patch)/logs/stdio
Anybody know what's going on?
Patch Set 3:
And now the chromeos builder is unhappy, see
https://build.chromium.org/deprecated/tryserver.chromium.chromiumos/builders/chromeos-daisy-rel/builds/23331/steps/compile%20(with%20patch)/logs/stdioAnybody know what's going on?
There's missing dependencies; the constituent targets of platform (in this case, instrumentation) need to have a transitive dependency on the build flag header, else it's not guaranteed to be generated in time for their compile steps.
This is a bit of a mess in platform right now; aside from combining it into one target (which is the simplest approach, and I think where we used to be), we can mimic blink_core to some extent and address it.
https://chromium-review.googlesource.com/c/chromium/src/+/830687 is a working prototype of that which fixes this issue in my local testing and passes the CQ. I can probably split off the generic refactoring of that into a separate CL to land in front of this one.
Patch Set 3:
Patch Set 3:
And now the chromeos builder is unhappy, see
https://build.chromium.org/deprecated/tryserver.chromium.chromiumos/builders/chromeos-daisy-rel/builds/23331/steps/compile%20(with%20patch)/logs/stdioAnybody know what's going on?
There's missing dependencies; the constituent targets of platform (in this case, instrumentation) need to have a transitive dependency on the build flag header, else it's not guaranteed to be generated in time for their compile steps.
This is a bit of a mess in platform right now; aside from combining it into one target (which is the simplest approach, and I think where we used to be), we can mimic blink_core to some extent and address it.
https://chromium-review.googlesource.com/c/chromium/src/+/830687 is a working prototype of that which fixes this issue in my local testing and passes the CQ. I can probably split off the generic refactoring of that into a separate CL to land in front of this one.
Would be awesome if you could land a refactoring that cleans this up :)
jbroman: fyi, this seems to work now :)
hooray \o/
Patch set 5:Code-Review +1
Patch set 5:Commit-Queue +2
Commit Bot merged this change.
Reland "[oilpan] Move incremental marking behind a build-time flag"
This is a reland of 9966b73a986a5de99d3ba51d0d587b17fd0b938d
Original change's description:
> [oilpan] Move incremental marking behind a build-time flag
>
> Move Oilpan's incremental marking work behind a build-time flag
> enable_blink_heap_incremental_marking
>
> Bug: chromium:757440
> Change-Id: Id4adddcf0669dc165935eced90e8caefbb76a094
> Reviewed-on: https://chromium-review.googlesource.com/822492
> Commit-Queue: Michael Lippautz <mlip...@chromium.org>
> Reviewed-by: Kentaro Hara <har...@chromium.org>
> Reviewed-by: Dirk Pranke <dpr...@chromium.org>
> Reviewed-by: Jeremy Roman <jbr...@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#524051}
Bug: chromium:757440
Change-Id: I56d11f001fc2717329b3caf0e815adac76b6ddb2
Reviewed-on: https://chromium-review.googlesource.com/828734
Reviewed-by: Jeremy Roman <jbr...@chromium.org>
Reviewed-by: Kentaro Hara <har...@chromium.org>
Commit-Queue: Michael Lippautz <mlip...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525079}
---
M third_party/WebKit/Source/platform/BUILD.gn
M third_party/WebKit/Source/platform/heap/BUILD.gn
M third_party/WebKit/Source/platform/heap/IncrementalMarkingTest.cpp
M third_party/WebKit/Source/platform/heap/Member.h
M third_party/WebKit/Source/platform/heap/ThreadState.cpp
5 files changed, 25 insertions(+), 9 deletions(-)