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
This commits a rewrite of the Breakpad Linux client.
The old code:
* Had a number of plain bugs in it, but those could just have been
fixed.
* Allocated memory from the heap, which is a no go.
* Made libc calls which can enter the dynamic linker - another source
of crashes.
* Didn't understand some of the tricks needed, like clone() via libc
will write to random areas of memory because it assumes that it's
only called from libpthread
Additionally, we had one more requirement which meant changing the
interface:
* We need to be able to crash dump the renderers from the browser
process.
And that last one really needed a rewrite.
We intend to try and upstream this new code into Breakpad.
The new Breakpad design works like this:
When a renderer crashes, a signal handler runs on an alternative stack
and collects information about the registers of the thread before the
crash. Then we enter Chromium specific code an send a datagram message
to a magic file descriptor (4) containing:
* the registers and tid of the crashing thread
* the active URL
* a file descriptor to a socket
* a CREDENTIALS structure giving the PID of the renderer.
On the other end of the socket is an object on the IO thread
(render_crash_handler_host_linux.cc) which reads and parses the
datagram. The CREDENTIALS structure is validated by the kernel, so the
renderer can't lie about it's PID and try and get the browser to crash
dump the wrong process.
The browser then ptraces the renderer and extracts all the needed
information to write a minidump to a temp file. Then we write a byte
to the file descriptor which the renderer gave the browser in the
datagram and that's the signal to the renderer to finish dying. It
dies by sending itself the same signal which trigger the crash dump in
the first place, so it will appear to crash as normal as far as kernel
core dumps and waitpid are concerned.
The browser then constucts a MIME message in a temp file for upload to
the crash service. We then fork out to /usr/bin/wget to actually do
the upload (since Debian numbers suggest that 99.8% of users have wget
installed.) A second forked child unlinks the temp files once wget has
completed.
For a browser crash, everything works pretty much the same except that
the datagram step is omitted and we clone() off a process to ptrace
ourselves and write the minidump.
This code is only enabled in Chrome branded builds. Stub source files
are substituted in the case of a Chromium build.
http://codereview.chromium.org/115526
BUG=9646,10772
TEST=Build a Chrome branded binary. Send SEGV to a renderer and verify that wget output appears on stderr. Send a SEGV to the main binary and verify the same.
git-svn-id: http://src.chromium.org/svn/trunk/src/build@16719 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Explicitly disable it (/INCREMENTAL:NO) for Release, and for the
following targets that require it:
chrome.dll
interactive_ui_tests.exe
perf_tests.exe
unit_tests.exe
Explicitly specificy /SUBSYSTEM:CONSOLE as default for linking,
and match current practice by overriding with /SUBSYSTEM:WINDOWS for:
chrome.exe
chrome.dll
media_player.exe
sandbox_poc.exe
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/115664
git-svn-id: http://src.chromium.org/svn/trunk/src/build@16698 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Added a default in common.gypi to remove headers from all mac applications that are bundles.
Added a var to control the inclusion of keystone to chrome.gyp defaulted on branding and then honor it for the shipping work.
Review URL: http://codereview.chromium.org/113652
git-svn-id: http://src.chromium.org/svn/trunk/src/build@16510 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This provides basic support for looking up backtrace information on GNU libc systems and in Windows. The code is only enabled for FATAL log messages in debug mode. In a release build, it is unlikely that symbols will be available making the backtrace less useful.
Review URL: http://codereview.chromium.org/62140
git-svn-id: http://src.chromium.org/svn/trunk/src/build@14391 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
optimization level used for debug builds on linux.
They still default to -O0, but you can set them to -O1 by
doing 'gyp -Ddebug_optimize=1'.
This cuts valgrind runtime without screwing up stack dumps too badly.
On the buildbot, the easiest way to use this is to
create the file ~/.gyp/include.gypi by hand, containing the lines
# Override for valgrind buildbot
{
'variables': {
'debug_optimize': '1',
},
}
From then on, any "gclient sync" run, when it runs gyp after finishing,
will cause debug builds to use -O1. This is a bit obscure, but
it's a heck of a lot easier than threading some flag value
through the buildbot scripts or adding a new build mode.
Review URL: http://codereview.chromium.org/67199
git-svn-id: http://src.chromium.org/svn/trunk/src/build@14046 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Only base_unittests included for now. Linux changes added as well but
untested until Linux switches to gyp.
Enable coverage with the following command:
src/tools/gyp/gyp_dogfood -Dcoverage=1 src/build/all.gyp
Review URL: http://codereview.chromium.org/56136
git-svn-id: http://src.chromium.org/svn/trunk/src/build@13068 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
variables ($CC, $DISTCC_DIR, $HOME, etc.).
Accomodate spelling change ($CHROME_SRC_DIR => $SRC_DIR) that
makes the gyp SCons a little more generic.
Use the new $LIB_DIR variable the gyp SCons generator now defines for us.
Review URL: http://codereview.chromium.org/42650
git-svn-id: http://src.chromium.org/svn/trunk/src/build@12583 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
* Add Linux settings to target_defaults in common.gypi so
gyp-generated SConscript files no longer depend on
build/SConscript.main or the Hammer infrastructure.
* Copy the FilterOut() function from Hammer to the chromium_builders.py
Tool module.
* Add a ChromiumLoadableModule() builder to chromium_builders.py.
* Add dependencies on the 'views' library to the chrome link (target 'app').
* Add missing views/*/*_unittest.cc modules to the 'unit_tests' target.
Exclude all but the one that builds on Linux from the non-Windows builds.
* Crib a list of chrome/views files to exclude from the Linux build
from the old SCons configuration.
* Add a new build/linux/system.gyp file with new 'settings' targets
to encapsulate the pkg-config checks for gtk+-2.0, nss and pangoft2.
* Add depenedencies in the other targets on the new gtk, nss and
pangoft2 'settings' targets from build/linux/system.gyp.
* Add a pkg_config_wrapper.py script that keeps gyp happy by
simply exiting 0 if the package isn't found.
* DEPS roll for latest gyp changes to support the above.
Review URL: http://codereview.chromium.org/42340
git-svn-id: http://src.chromium.org/svn/trunk/src/build@12228 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
- Remove the use of the mac specific type 'application' and use 'executable'
with 'mac_bundle' set to 1.
- update common.gypi to default mac_bundle to zero.
- update common.gypi to look at mac_bundle for some of the base behaviors that
were on 'application'.
- Roll DEPS to get the new version of gyp w/ the matching support.
Review URL: http://codereview.chromium.org/50015
git-svn-id: http://src.chromium.org/svn/trunk/src/build@12136 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
bradnelson@chromium.org
thestig@chromium.org
yutak@chromium.org
mark@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
dank@chromium.org
deanm@chromium.org
evan@chromium.org
dkegel@google.com
thomasvl@chromium.org
brettw@chromium.org
jrg@chromium.org
nsylvain@chromium.org
bradnelson@google.com
sehr@google.com
mmoss@chromium.org
ajwong@chromium.org
hclam@chromium.org
nick@chromium.org
sky@chromium.org
tc@google.com
ben@chromium.org
dglazkov@chromium.org
awalker@google.com
pinkerton@chromium.org
dimich@google.com