This is an experiment to get a few test cycles in so that we can measure the
impact and evaluate it against the .app/.dmg size increase that it will cause.
The size increase relative to -O2 is 1900kB (6%) .app and 800kB (5%) .dmg.
BUG=16713
TEST=Watch perf
Review URL: http://codereview.chromium.org/173505
git-svn-id: http://src.chromium.org/svn/trunk/src/build@24511 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
BUG=16713
TEST=Watch perf. Startup time should be flat or possibly lose a very small
amount (~1%). Everything else should be a little bit faster.
Watch sizes. The .app and .dmg will grow, but I've cut their sizes way
down lately, and I'd like to cash in some of those gains for speed.
Review URL: http://codereview.chromium.org/174160
git-svn-id: http://src.chromium.org/svn/trunk/src/build@23882 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
consumers use executeCommand.
Patch by Marshall Greenblatt
R=darin
BUG=19270
TEST=covered by unit tests
git-svn-id: http://src.chromium.org/svn/trunk/src/build@23442 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This will eliminate the cxa_guard_acquire/release locks around static guard
accesses. The Windows compiler doesn't support thread-safe statics at all,
so none of our cross-platform code relies on thread safety. We are using
-fno-threadsafe-statics on Linux as well, since r20616. It's likely that
threading is not a concern in most to all Mac-specific code using statics.
BUG=16713
TEST=none
Review URL: http://codereview.chromium.org/165461
git-svn-id: http://src.chromium.org/svn/trunk/src/build@23326 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
build, where C++ exceptions are already disabled.
BUG=19094 12248
TEST=Mac release-mode Google Chrome.app should shrink by about 6MB.
Mac disk image should shrink by about 1.5MB.
Linux binary and package should shrink too.
Review URL: http://codereview.chromium.org/165330
git-svn-id: http://src.chromium.org/svn/trunk/src/build@23304 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Purify
Release - no tcmalloc
This is done more pedantically than I'd like,
so I've left in some TODOs. Eventually either gyp needs to support some
notion of inheritance in configurations, or maybe we can make clever use
of includes.
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/159362
git-svn-id: http://src.chromium.org/svn/trunk/src/build@22433 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
CrxInstaller is a new stateful object that encapsulates a
single installation from unpack through notification.
It currently contains the UI bits, but I suspect in the next
CL (where I will finally implement the install UI) these
will come out and CrxInstaller will become
SilentCrxInstaller, and only used for updates and external
installs.
Also in this change, I removed the concept of install callbacks that ExtensionUpdater was using. This was only used to delete the temp crx file as far as I can tell, and we can easily keep state about that in CrxInstaller.
With this CL, ExtensionsServiceBackend is almost completely
dead, with only a few zombie methods left like
LoadAllExtensions(). These should all become little objects
like CrxInstaller that hold a reference to ExtensionsService
over their lifetime and then kill themselves.
I'll get to that eventually.
Review URL: http://codereview.chromium.org/160311
git-svn-id: http://src.chromium.org/svn/trunk/src/build@22043 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Switching two includes in common.gypi to msvs_system_include_dirs.
This will force them to the back of the include order (which matches
where the non-hermetic copies of these libraries would be).
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/155812
git-svn-id: http://src.chromium.org/svn/trunk/src/build@21124 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This patch removes the hardcoded paths for the sandbox binary location
and the chrome binary location for the sandbox. Instead, you can now
set GYP variables for these things. Indeed, you have to set a GYP
variable in order to use the sandbox now.
GYP variables can be set on the command line, if you run gyp.py
directly, with -D key=value. Or you can export GYP_DEFINES="key=value
key2=value2".
Now, in order to use the sandbox you should set:
linux_sandbox_path=/opt/google/chrome/chrome-sandbox
linux_sandbox_chrome_path=/opt/google/chrome/chrome
(changing the paths as needed, of course). See the comments in
build/common.gypi
For development see
http://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment
Because developers need to setup a special sandbox binary.
http://codereview.chromium.org/149689
git-svn-id: http://src.chromium.org/svn/trunk/src/build@20801 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The latest google-chrome packages contain a sandbox binary, which the
development builds of chromium will pick up on automatically. However,
for safety reasons, the sandbox binary will only exec a fixed chrome
binary location. Since development builds will be somewhere else in
the filesystem, this means that they will fail to start their zygote
processes and generally be very sad.
However, we /do/ want people developing with the sandbox, but we don't
want the general sandbox binary to be able to exec anything. We could
have chromium try and find its sandbox binary relative to the build
directory, but some people build on NFS and, since the sandbox binary
needs to be SUID, this won't work for them.
Instead, we add a new target: chrome_devel_sandbox which developers
can use. This builds a sandbox binary that will exec anything which is
owned by the running user. This alternative sandbox binary can be
selected by exporting CHROME_DEVEL_SANDBOX.
git-svn-id: http://src.chromium.org/svn/trunk/src/build@20709 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
We already depend on our static initializers being thread safe, since MSVC does
not implement locking around static initialization. This avoids extra locking
(__cxa_guard_acquire / __cxa_guard_release).
Review URL: http://codereview.chromium.org/149607
git-svn-id: http://src.chromium.org/svn/trunk/src/build@20616 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Currently we have several uses of %I64d in format strings to indicate
a 64-bit value. This does not work on Mac or Linux, where 'I'
indicates the use of locale specific digits.
Instead, we introduce base/format_macros.h which mimic the C99
standard macros for 64-bit values in a cross-platform manner.
Dean pointed out that V8 is handling this themselves rather than use
inttypes.h. Maybe we'll end up going down the same path but, for the
moment, we'll try and do it the 'correct' way and see how it works
out.
http://codereview.chromium.org/147154
git-svn-id: http://src.chromium.org/svn/trunk/src/build@19500 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This notion was previously overloaded on "branding", but as implied, that
variable should really just control the "Google Chrome" vs. "Chromium"
branding. We need a separate setting to distinguish between "release" builds
(which get special handling, like breakpad symbol processing), and "everyday"
builds, like the buildbot continuous builds or personal developer builds.
This fixes a problem where the "Google Chrome" continuous builder was
unnecessarily trying to upload breakpad symbols for every single build.
Review URL: http://codereview.chromium.org/132038
git-svn-id: http://src.chromium.org/svn/trunk/src/build@19283 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
We already depend on our static initializers being thread safe, since
MSVC does not implement locking around static initialization. This avoids
extra locking (__cxa_guard_acquire / __cxa_guard_release).
Review URL: http://codereview.chromium.org/126267
git-svn-id: http://src.chromium.org/svn/trunk/src/build@18700 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
thestig@chromium.org
dank@chromium.org
bradnelson@google.com
mark@chromium.org
bradnelson@chromium.org
yutak@chromium.org
sgk@google.com
munjal@chromium.org
darin@chromium.org
agl@chromium.org
sidchat@google.com
tim@chromium.org
piman@chromium.org
aa@chromium.org
deanm@chromium.org
evan@chromium.org
dkegel@google.com
thomasvl@chromium.org
brettw@chromium.org
jrg@chromium.org
nsylvain@chromium.org
sehr@google.com
mmoss@chromium.org
ajwong@chromium.org