OLD | NEW |
(Empty) | |
| 1 # Introduction |
| 2 |
| 3 A build mode where chrome.dll is split into two separate DLLs. This was undertak
en as one possible workaround for toolchain limitations on Windows. |
| 4 |
| 5 |
| 6 # Details |
| 7 |
| 8 ## How |
| 9 |
| 10 Normally, you probably don't need to worry about doing this build. If for some r
eason you need to build it locally: |
| 11 |
| 12 * From a _Visual Studio Command Prompt_ running as **Administrator** run `pyth
on tools\win\split_link\install_split_link.py`. |
| 13 * Set `GYP_DEFINES=chrome_split_dll=1`. In particular, don't have `component=s
hared_library`. Other things, like `buildtype` or `fastbuild` are fine. |
| 14 * `gclient runhooks` |
| 15 * `ninja -C out\Release chrome` |
| 16 |
| 17 `chrome_split_dll` currently applies only to chrome.dll (and not test binaries). |
| 18 |
| 19 ## What |
| 20 |
| 21 This is intended to be a temporary measure until either the toolchain is improve
d or the code can be physically separated into two DLLs (based on a browser/chil
d split). |
| 22 |
| 23 The link replacement forcibly splits chrome.dll into two halves based on a descr
iption in `build\split_link_partition.py`. Code is primarily split along browser
/renderer lines. Roughly, Blink and its direct dependencies are in the "chrome1.
dll", and the rest of the browser code remains in "chrome.dll". |
| 24 |
| 25 Splitting the code this way allows keeping maximum optimization on the Blink por
tion of the code, which is important for performance. |
| 26 |
| 27 There is a compile time define set when building in this mode `CHROME_SPLIT_DLL`
, however it should be used very sparingly-to-not-at-all. |
| 28 |
| 29 ## Details |
| 30 |
| 31 This forcible split is implemented by putting .lib files in either one DLL or th
e other, and causing unresolved externals that result during linking to be forci
bly exported from the other DLL. This works relatively cleanly for function impo
rt/export, however it cannot work for data export. |
| 32 |
| 33 There are relatively few instances where data exports are required across the DL
L boundary. The waterfall builder http://build.chromium.org/p/chromium/waterfall
?show=Win%20Split will detect when new data exports are added, and these will ne
ed to be repaired. For constants, the data can be duplicated to both DLLs, but f
or writeable data, a wrapping set/get function will need to be added. |
| 34 |
| 35 Some more details can be found on the initial commit of the split\_link script h
ttp://src.chromium.org/viewvc/chrome?revision=200049&view=revision and the assoc
iated bugs: http://crbug.com/237249 http://crbug.com/237267 |
OLD | NEW |