[linux] components build
Evan Martin
build configuration on Linux that builds Chrome as a collection of
shared libraries. Rather than producing a 900mb debug chrome binary,
you get a 400mb chrome binary and another 600mb of libskia, libwebkit,
etc. This improves build times as you don't have to do as much work
for each incremental link.
Here are some numbers.
- Deleting Chrome binary and rebuilding: static link: 30s / components: 12s.
- Touching chrome/app/chrome_main_posix.cc and rebuilding: static
link: 30s (.o likely comes out of a cache) / components: 13s (I
expected this to be slower, hmm).
To use:
./build/gyp_chromium -Dcomponent=shared_library
or
export GYP_DEFINES=component=shared_library; rerun gyp.
I'll update the LinuxFasterBuilds wiki page with this info.
FAQ:
Q. How is this different than the "shlib" / "shared" build?
A. The shared build worked by making a .so out of roughly every gyp
target, and then globally exposing every function between them. It
was fragile and required some hacks at the build system level. The
components build instead builds a .so out of specific hand-picked
components, and explicitly marks all the API we expect a component to
expose to other components. Because it uses the same gyp rules the
Windows components build does, I expect it to break more rarely. We
intend to replace the linux-shlib buildbot with a linux-components
bot.
Q. Why is the chrome binary still so huge?
A. Ricardo is still working on splitting out other parts of Chrome
into components. For example, currently all of net/ is still just
linked into the main binary, which means that chrome and test_shell
each get their own copy as they do in the static build. (See
http://code.google.com/p/chromium/issues/detail?id=76997 .) As this
work progresses we will divide into smaller pieces.
$ du -sh lib/* | sort -rn
493M lib/libwebkit.so
52M lib/libv8.so
13M lib/libicuuc.so
11M lib/libbase.so
9.5M lib/libskia.so
9.5M lib/libgoogleurl.so
6.2M lib/libicui18n.so
5.3M lib/libffmpegsumo.so
Q. Wait, we're declaring stable APIs between parts of Chrome? Does
this mean I can version and ship these libraries separately?
A. No! For any given snapshot of the tree we expect the code to
compile together, but beyond that this is purely a build-time hack for
now. Please continue to modify code as you see fit.
Q. How do I debug problems with this?
A. You'll typically get linker errors if something goes wrong. Look
at what the symbol is, where it should be coming from, and verify it's
been marked public and that it's getting linked into the target. Ping
me if you need help.
Q. What's up with Release builds?
A. Still looking into it. But for Release builds, it only takes a few
seconds to link in the static build configuration anyway.
Q. And nacl?
A. Until I wrote this mail I had forgotten I build with nacl disabled,
but it seems like I can't get it to build right now no matter the
build configuration. Probably some local issue. Your help on
improving this is welcome. :)
Q: How about Mac?
A. I think it ought to work similarly to Linux, but I am Mac-ignorant.
I recommend supplying Mark with bribes and caffeine.
William Chan (陈智昌)
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Darin Fisher
The intent is for the components build to be the default build for developers. Evan mentioned converting the shlib buildbot.
William Chan (陈智昌)
Evan Martin
> Q. What's up with Release builds?
> A. Still looking into it. But for Release builds, it only takes a few
> seconds to link in the static build configuration anyway.
Release builds seem to work with trunk now. So in theory it's safe to
turn on components always.
James Robinson
Evan Martin
> On Fri, May 6, 2011 at 4:31 PM, Evan Martin <ev...@chromium.org> wrote:
>>
>> On Fri, May 6, 2011 at 10:34 AM, Evan Martin <ev...@chromium.org> wrote:
>> > Q. What's up with Release builds?
>> > A. Still looking into it. But for Release builds, it only takes a few
>> > seconds to link in the static build configuration anyway.
>>
>> Release builds seem to work with trunk now. So in theory it's safe to
>> turn on components always.
>
> What build targets does this include? Currently in Debug I can build
> 'chrome' and some other targets like 'unit_tests' and 'test_shell' but I get
> lots of link errors on DumpRenderTree.
It works for the ones I tried. ;)
Sorry, I'll look into DumpRenderTree too.
Evan Martin
>> turn on components always.
>
> What build targets does this include? Currently in Debug I can build
> 'chrome' and some other targets like 'unit_tests' and 'test_shell' but I get
> lots of link errors on DumpRenderTree.
DRT builds in this configuration as of WebKit r86080 (from an hour ago or so).