blink_platform now completely factored out of Core

[Adam Barth]

As of http://src.chromium.org/viewvc/blink?view=revision&revision=166660, we have completely removed core/platform.  All the platform code is now factored into a separate blink_platform target, which links separately from core.  We also have DEPS rules and link-time contraints to prevent future bad dependencies from creeping in.

Many thanks to everyone who contributed to this effort, including the folks below:

• adam.treat
  
• adamk
  
• ckocagil
  
• dcheng
  
• eae
  
• eseidel
  
• jbroman
  
• kinuko
  
• mvujovic
  
• pilgrim
  
• rafaelw
  
• rob.buis
  
• schenney
  
• tfarina
  
• tkent
  

Happy hacking!

Adam

[Eric Seidel]

Woohooo! Huge thanks to the tireless efforts of all those
contributors in the last 6 months!


My understanding is that next in line in splitting bindings/ into bits
below core/ and bits above core? And once that's split then we can
split modules/ into a separate dylib?

Presumably this is something we'll discuss at much greater length at
BlinkOn2. :)

[Adam Barth]

On Thu, Feb 6, 2014 at 6:21 PM, Eric Seidel <ese...@chromium.org> wrote:

Woohooo!  Huge thanks to the tireless efforts of all those
contributors in the last 6 months!

My understanding is that next in line in splitting bindings/ into bits
below core/ and bits above core?  And once that's split then we can
split modules/ into a separate dylib?

There still a few more things we need to do before we can actually load modules as a separate dylib:

1) There's a circular dependency between Source/core and Source/web.  Until that dependency is broken, we won't be able to break down the core dylib much.  To see an example of this circular dependency, notice that ApplicationCacheHost.cpp is in Source/web but defines a number of symbols in the WebCore namespace.  Because those symbols are declared in Source/core and defined in Source/web, Core won't link without Web.  Mark Pilgrim has removed a large number of these bad dependencies, but there are still a number of them left.  Once we remove these dependencies, we should be able to link Source/web as a separate dylib (e.g., blink_web.dll).

2) As you mention, there's a circular dependency between Source/core and Source/bindings.  Specifically, Source/core calls a number of functions in Source/bindings (e.g., functions on ScriptValue and ScriptController), and the bindings we generate from WebIDL calls back into core (e.g., V8Node calls functions on Node).  We don't need to fully disentangle these parts of the system.  All we really need to do is separate out the bindings that calls into modules (i.e., the bindings generated from WebIDL in Source/modules).  The approach I'd try first is, as you mention, to split the bindings into two pieces: one that's intertwined with Core and another piece that has dependencies on Core and Modules but no dependencies from Core or Modules.

3) The last piece of the puzzle is the inspector, but I haven't quite figured out how the inspector fits in.  This might be a good topic to discuss at BlinkOn2.  One approach is for the inspector to link as a separate dylib that sits above both Core and Modules but below Web.  In that approach, Core and Modules could expose virtual interfaces that call up to the inspector.  For example, InspectorResourceAgent could become a virtual interface.  Another approach is to split the inspector code into multiple pieces and link each piece into the dylib that it's inspector.  For example, the InspectorDatabaseAgent would be linked into modules/webdatabase.  In this approach, we'd presumably need some coordination code linked into blink_web.dl.

Each of those steps is a fair bit of work.  However, now that we've broken the circular dependency between Platform and Web, we're in a much better position to make progress.

Presumably this is something we'll discuss at much greater length at
BlinkOn2. :)

I'd very interested in ideas folks have for solving (3).

Adam

[Vladislav Kaznacheev]

Hi Adam,

The inspector piece of the puzzle is actually already solved. Over the last week I have landed a number of patches against crbug.com/340221. The one remaining patch (https://chromiumcodereview.appspot.com/147353007) is in CQ right now. 

The approach I have taken is the latter of the two that you have suggested: InspectorDatabaseAgent moves under modules/webdatabase and plugs itself into the inspector machinery by calling InspectorController::registerModuleAgent.

By the time the last patch is committed there will be zero references from core/inspector to modules.

'grep -R "#include \"modules" Source/core' will still return 7 lines outside core/inspector.

Best regards,

  Vlad

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Adam Barth]

Awesome!  Thank you for working on this problem.

Adam