Chromium multi DLL dev build for Windows

[Victor Wang]

Hi,

I added a new build mode for chromium Windows. The new mode generates DLLs for major components like webkit, v8, icu, googleurl etc.

If you are a windows developer and would like to try it out. Get the latest code and do one of the following to enable this mode:

1. Override the "component" variable with "shared_library" when running gyp:

    python build\gyp_chromium -D"component=shared_library"

2. Add the following line to your .gyp/include.gypi and regenerate projects:

    {'variables': {'component': 'shared_library'}}

    Note: this will affect all your chromium projects. It also changes the build mode when you run "gclient sync".

The multi dll build is still in experimental. If you see any issues (build break, crashes etc), feel free to email me, or file a bug and assign to me, or even better, go ahead and fix it:).

Let me know of any questions.

Thanks,

Victor

[Evan Martin]

This sounds great!

I see from your changes that you're aware of the
library=shared_library hack some people have been using on Linux.
What is your opinion of it? It seems to me the fewer levers we have
in the gyp file the better, so I'm tempted to deprecate the library
variable in favor of using component on all platforms.

The other piece to that is to ask, how Windows-specific is it? I
noticed in changes like
http://codereview.chromium.org/3053011/diff/1/2
you put the test under a Windows-only branch...

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>

[Dirk Pranke]

Hi Victor,

This sounds cool, but, for the uninitiated, can you describe what the
advantages (and presumably fewer disadvantages) of a multi-DLL build
are?

-- Dirk

On Thu, Jul 22, 2010 at 2:36 PM, Victor Wang <vic...@chromium.org> wrote:

[Victor Wang]

On Thu, Jul 22, 2010 at 5:28 PM, Evan Martin <ev...@chromium.org> wrote:

This sounds great!

I see from your changes that you're aware of the
library=shared_library hack some people have been using on Linux.
What is your opinion of it?  It seems to me the fewer levers we have
in the gyp file the better, so I'm tempted to deprecate the library
variable in favor of using component on all platforms.

For the new chromium multi dll build, not every target is built as DLL (at least for now). Only major components are built as DLL on windows, so we still need variable library for targets that are built as shared library on linux but static library on windows.

 

The other piece to that is to ask, how Windows-specific is it?  I
noticed in changes like
 http://codereview.chromium.org/3053011/diff/1/2
you put the test under a Windows-only branch...

The DLL stuff I have done so far is just for windows. Haven't look at how to do this for mac, but we should be able to share the new variable component for the same purpose on mac. Maybe some mac experts can share their thoughts on how this works for mac...

[Victor Wang]

For the multi dll build, the main pro is faster link time. It will have slower loading time. This is for developer build and will not use in production, so I think this trade off should be fine...

Thanks,

Victor

[Darin Fisher]

On Thu, Jul 22, 2010 at 5:28 PM, Evan Martin <ev...@chromium.org> wrote:

This sounds great!

I see from your changes that you're aware of the
library=shared_library hack some people have been using on Linux.
What is your opinion of it?  It seems to me the fewer levers we have
in the gyp file the better, so I'm tempted to deprecate the library
variable in favor of using component on all platforms.

it might be a good idea so that we just have fewer configs.  that'll help

minimize maintenance cost.  however, it may not be as nice as what

you have today on linux....

on linux, thanks to the way the linker works, you can have .so files with

undefined symbols.  that means you can have circular dependencies.

as a result, you can have many more .so files with relative ease.  on

windows it doesn't work that way, so we had to invent the notion of

components, where components have clearly defined dependencies (no

cycles).

eventually the plan includes getting buildbots setup with this new build

config, and it should probably be made the default config for developers.

-darin

[stoyan]

On Thu, Jul 22, 2010 at 11:43 PM, Darin Fisher <da...@chromium.org> wrote:
> on linux, thanks to the way the linker works, you can have .so files with
> undefined symbols.  that means you can have circular dependencies.
> as a result, you can have many more .so files with relative ease.  on
> windows it doesn't work that way, so we had to invent the notion of
> components, where components have clearly defined dependencies (no
> cycles).

FWIW on windows having circular dependencies is OK. Two DLLs can
import from each other (HAL and NTOSKRNL are the most famous example),
this is the exact reason why the .EXP files have been invented.

Stoyan

[Darin Fisher]

Right... my understanding is that it is just a pain to set that up and maintain

it.  Or, am I mistaken?

-Darin 

[Victor Wang]

FYI: Multi dll build saves me ~50 seconds (~6%) for a clean chrome.exe build on my local machine.