Build WTF as dll in component build

Build WTF as dll in component build

This componentizes WTF so it builds as a separate DLL in the component
build. This slightly (~10% on mac debug) decreases the size of the main Blink
DLL and is a prerequisite for componentizing other parts of the Blink codebase.
This patch is mostly mechanically adding export annotations to symbols used
outside WTF, but it also changes the way that platform capabilities are injected
into WTF to passing function pointers in during WebKit::initialize.

TBR=darin@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=151200

[jamesr, 2013-05-25 20:11:39]

https://codereview.chromium.org/15861022/diff/1/Source/WebKit/chromium/src/We...
File Source/WebKit/chromium/src/WebKit.cpp (right):

https://codereview.chromium.org/15861022/diff/1/Source/WebKit/chromium/src/We...
Source/WebKit/chromium/src/WebKit.cpp:151:
WTF::setRandomSource(cryptographicallyRandomValues);
these have to be set before WTF::initializeThreading(). these probably could use
wtf/Functional.h + bind() instead of function pointers, but I couldn't figure
out how that stuff works for parameterized functions.

https://codereview.chromium.org/15861022/diff/1/Source/WebKit/chromium/src/We...
Source/WebKit/chromium/src/WebKit.cpp:153:
WTF::initializeMainThread(callOnMainThreadFunction);
callOnMainThread is something we should probably remove from WTF completely.

[jamesr, 2013-05-25 20:21:16]

Another possibility this enables is having a wtf_unittests target that depends
only on wtf.dll instead of having those tests be in webkit_unit_tests.  It'll
require the wtf_unittests executable provide the currentTime/etc functions, but
we can do that using webkit_support.

When this patch looks ready I'll send a brief description/refresher on the
component build to blink-dev@ since I think blink developers who don't spend a
lot of time with chromium code may not be as familiar with the configuration.

[darin (slow to review), 2013-05-25 21:42:43]

LGTM

https://codereview.chromium.org/15861022/diff/1/Source/WebKit/chromium/src/We...
File Source/WebKit/chromium/src/WebKit.cpp (right):

https://codereview.chromium.org/15861022/diff/1/Source/WebKit/chromium/src/We...
Source/WebKit/chromium/src/WebKit.cpp:151:
WTF::setRandomSource(cryptographicallyRandomValues);
On 2013/05/25 20:11:39, jamesr wrote:
> these have to be set before WTF::initializeThreading(). these probably could
use
> wtf/Functional.h + bind() instead of function pointers, but I couldn't figure
> out how that stuff works for parameterized functions.

Would it make sense for these to become parameters to initializeThreading? 
Maybe initializeThreading should be renamed initialize?

https://codereview.chromium.org/15861022/diff/1/Source/WebKit/chromium/src/We...
Source/WebKit/chromium/src/WebKit.cpp:153:
WTF::initializeMainThread(callOnMainThreadFunction);
On 2013/05/25 20:11:39, jamesr wrote:
> callOnMainThread is something we should probably remove from WTF completely.

+1

https://codereview.chromium.org/15861022/diff/1/Source/bindings/v8/ScriptCont...
File Source/bindings/v8/ScriptController.cpp (right):

https://codereview.chromium.org/15861022/diff/1/Source/bindings/v8/ScriptCont...
Source/bindings/v8/ScriptController.cpp:98:
WTF::initializeMainThread(callOnMainThreadFunction);
Why does ScriptController::initializeThreading exist?  Isn't this redundant with
WebKit::initialize?

It seems to only get called by DatabaseManager.cpp:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

Very odd.

https://codereview.chromium.org/15861022/diff/1/Source/wtf/CryptographicallyR...
File Source/wtf/CryptographicallyRandomNumber.cpp (right):

https://codereview.chromium.org/15861022/diff/1/Source/wtf/CryptographicallyR...
Source/wtf/CryptographicallyRandomNumber.cpp:173: 
nit: bogus new line?

[jamesr, 2013-05-25 22:14:03]

On 2013/05/25 20:21:16, jamesr wrote:
> Another possibility this enables is having a wtf_unittests target that depends
> only on wtf.dll instead of having those tests be in webkit_unit_tests.  It'll
> require the wtf_unittests executable provide the currentTime/etc functions,
but
> we can do that using webkit_support.

Actually, don't even need that!  https://codereview.chromium.org/16066003 for
wtf_unittests that depends only on gtest/gmock and wtf.

[jamesr, 2013-05-26 01:09:10]

https://codereview.chromium.org/15861022/diff/1/Source/WebKit/chromium/src/We...
File Source/WebKit/chromium/src/WebKit.cpp (right):

https://codereview.chromium.org/15861022/diff/1/Source/WebKit/chromium/src/We...
Source/WebKit/chromium/src/WebKit.cpp:151:
WTF::setRandomSource(cryptographicallyRandomValues);
On 2013/05/25 21:42:43, darin wrote:
> On 2013/05/25 20:11:39, jamesr wrote:
> > these have to be set before WTF::initializeThreading(). these probably could
> use
> > wtf/Functional.h + bind() instead of function pointers, but I couldn't
figure
> > out how that stuff works for parameterized functions.
> 
> Would it make sense for these to become parameters to initializeThreading? 
> Maybe initializeThreading should be renamed initialize?

I've hidden the time setters into a WTF::initialize() function. I've left the
crypto source separate for now - I think it might just be removed from WTF.  I
think it was useful to have these things in WTF back in WebKit so that JSC could
also use them, but for us it might not be as helpful to have it there.

https://codereview.chromium.org/15861022/diff/1/Source/bindings/v8/ScriptCont...
File Source/bindings/v8/ScriptController.cpp (right):

https://codereview.chromium.org/15861022/diff/1/Source/bindings/v8/ScriptCont...
Source/bindings/v8/ScriptController.cpp:98:
WTF::initializeMainThread(callOnMainThreadFunction);
On 2013/05/25 21:42:43, darin wrote:
> Why does ScriptController::initializeThreading exist?  Isn't this redundant
with
> WebKit::initialize?
> 
> It seems to only get called by DatabaseManager.cpp:
>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
> 
> Very odd.

The only way I can think that this would make sense is if the DatabaseManager
code could be reached before WebKit::initialize(), perhaps as part of the
browser webkit embedding?  Even that seems rather dubious.  I'll just nuke it
and see what breaks on the trybots.

[darin (slow to review), 2013-05-26 01:22:58]

OK, LGTM
On May 25, 2013 6:09 PM, <jamesr@chromium.org> wrote:

>
> https://codereview.chromium.**org/15861022/diff/1/Source/**
>
WebKit/chromium/src/WebKit.cpp<https://codereview.chromium.org/15861022/diff/1/Source/WebKit/chromium/src/WebKit.cpp>
> File Source/WebKit/chromium/src/**WebKit.cpp (right):
>
> https://codereview.chromium.**org/15861022/diff/1/Source/**
>
WebKit/chromium/src/WebKit.**cpp#newcode151<https://codereview.chromium.org/15861022/diff/1/Source/WebKit/chromium/src/WebKit.cpp#newcode151>
> Source/WebKit/chromium/src/**WebKit.cpp:151:
> WTF::setRandomSource(**cryptographicallyRandomValues)**;
> On 2013/05/25 21:42:43, darin wrote:
>
>> On 2013/05/25 20:11:39, jamesr wrote:
>> > these have to be set before WTF::initializeThreading(). these
>>
> probably could
>
>> use
>> > wtf/Functional.h + bind() instead of function pointers, but I
>>
> couldn't figure
>
>> > out how that stuff works for parameterized functions.
>>
>
>  Would it make sense for these to become parameters to
>>
> initializeThreading?
>
>> Maybe initializeThreading should be renamed initialize?
>>
>
> I've hidden the time setters into a WTF::initialize() function. I've
> left the crypto source separate for now - I think it might just be
> removed from WTF.  I think it was useful to have these things in WTF
> back in WebKit so that JSC could also use them, but for us it might not
> be as helpful to have it there.
>
> https://codereview.chromium.**org/15861022/diff/1/Source/**
>
bindings/v8/ScriptController.**cpp<https://codereview.chromium.org/15861022/diff/1/Source/bindings/v8/ScriptController.cpp>
> File Source/bindings/v8/**ScriptController.cpp (right):
>
> https://codereview.chromium.**org/15861022/diff/1/Source/**
>
bindings/v8/ScriptController.**cpp#newcode98<https://codereview.chromium.org/15861022/diff/1/Source/bindings/v8/ScriptController.cpp#newcode98>
> Source/bindings/v8/**ScriptController.cpp:98:
> WTF::initializeMainThread(**callOnMainThreadFunction);
> On 2013/05/25 21:42:43, darin wrote:
>
>> Why does ScriptController::**initializeThreading exist?  Isn't this
>>
> redundant with
>
>> WebKit::initialize?
>>
>
>  It seems to only get called by DatabaseManager.cpp:
>>
>
> https://code.google.com/p/**chromium/codesearch#chromium/**
> src/third_party/WebKit/Source/**modules/webdatabase/**
> DatabaseManager.cpp&q=**ScriptController::**initializeThreading&sq=**
>
package:chromium&type=cs&l=225<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/modules/webdatabase/DatabaseManager.cpp&q=ScriptController::initializeThreading&sq=package:chromium&type=cs&l=225>
>
>  Very odd.
>>
>
> The only way I can think that this would make sense is if the
> DatabaseManager code could be reached before WebKit::initialize(),
> perhaps as part of the browser webkit embedding?  Even that seems rather
> dubious.  I'll just nuke it and see what breaks on the trybots.
>
>
https://codereview.chromium.**org/15861022/<https://codereview.chromium.org/1...
>

[jamesr, 2013-05-27 23:15:57]

Adam, could you approve the ScriptController changes please?

[jamesr, 2013-05-27 23:43:22]

Committed patchset #4 manually as r151200 (presubmit successful).

[abarth-chromium, 2013-05-28 00:04:01]

The seem fine to me, but I don't have much more of a clue why that code existed
than you do.  :)