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
without tcmalloc for testing purpose. The linker complains about
_set_new_mode so I remove the call from the code for now.
Note this change is different from the change Bradley is working
on which provides an option for building chrome without tcmalloc.
This change simply removes tcmalloc from the build. The plan is
checking it in, keeping it in trunk for 24 hours, and then
reverting it. The benefits are
- Having another round of performance comparison between build
with and w/o tcmalloc.
- Having a full run of UI test under purify with tcmalloc disabled.
- Getting a verified CL in case we'd like to build an alternative
dev build w/o tcmalloc for A/B test.
Review URL: http://codereview.chromium.org/159599
git-svn-id: http://src.chromium.org/svn/trunk/src/build@22080 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
moving image_diff from chrome/tools/test/image_diff to tools/imagediff
(not moving to tools/image_diff to avoid some svn unpleasantness with that
directory having been created in CL 21366).
Also change test_shell.gyp to depend on everything needed to run the layout
tests.
R=darin@chromium.org
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/159361
git-svn-id: http://src.chromium.org/svn/trunk/src/build@21584 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
CL 21252 seems to have had some svn brokenness (not sure why). I've recreated
it and resubmitted it. The changes are to move image_diff from
chrome/tools/test to tools/, and to make test_shell depend on image_diff
and npapi_layout_test_plugin (and test_worker, where applicable)
R=nsylvain@chromium.org
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/155959
git-svn-id: http://src.chromium.org/svn/trunk/src/build@21366 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This splits the ipc code from the common project. The 'common' project pulls in
all of webkit, the v8 bindings, skia, googleurl, and a number of other projects
which makes it very difficult to deal with especially for external projects
wanting just to use some of Chromium's infrastructure. This puts the ipc code
into its top-level ipc/ directory with a dependency only on base. The common
project depends on the new ipc/ipc.gyp:ipc target so that all projects currently
pulling common in to get the IPC code still have it available. This mostly
follows agl's pre-gyp attempt to do this which was r13062.
Known issues:
- Currently a number of projects depend on chrome/chrome.gyp:common in order to
use the IPC infrastructure. Rather than fixing all of these dependencies I have
made common depend on ipc/ipc.gyp:ipc and added "ipc" to the include_rules
section of DEPS so that checkdeps.py doesn't complain. Over time projects that
need IPC should depend on the IPC project themselves and dependencies on common
removed, although I don't think many projects that need IPC will be able to get
away without common currently.
- ipc/ipc_message_macros.h still has #include "chrome/common/..." inside of a
ipc/ should not refer to files in chrome/... now. I'm not sure how to resolve
this since it's really an IDE bug
- the named pipe name (windows+linux) and the logging event name (all) + env
variable (posix) refer explicitly to 'Chrome' which somewhat hurts the illusion
of ipc/ being an independent library. I think this should be examined in a
subsequent, much smaller patch.
- I've eliminated the IPC.SendMsgCount counter since it was implemented in a way
to create a dependency from ipc/ to chrome/common/chrome_counters. This is the
same approach that r13062 took.
http://codereview.chromium.org/155905
(Patch from James Robinson)
git-svn-id: http://src.chromium.org/svn/trunk/src/build@21342 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Added a script to process a xib file and generate a localizer out of the resource constants it finds in the xib.
Update the MainMenu.xib to use a generated localizer.
Kill off the menu_localizer in favor of a generated one.
ui_localizer is a helper so each "localizer" is as small as possible.
Build some menus out of base strings and the product name like windows.
Added the dir generated for the localizers so we can load the header to directly create them (menubar one).
Enable the other 3 languages we were building to help test.
Made the context menu code use the new code for handling window's accelerators and ellipsis.
Added unittest for ui_localizer.
Opened http://crbug.com/17380 to track the problem with the menu titles so I can move on to other parts of the UI for now.
TEST=The main menu will have some items localized now (and more will be localizable in the TC).
BUG=16764
Review URL: http://codereview.chromium.org/155774
git-svn-id: http://src.chromium.org/svn/trunk/src/build@21272 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This adds project dependencies to test_shell so that all (and only?)
the targets needed for the layout_tests to run cleanly are built. On most
platforms this is test_shell, npapi_test_plugin, and test_worker, and on
the Mac this adds the layout_test_helper binary as well
also, this moves image_diff from chrome/tools/test to tools/
R=mmentovai@google.com, darin@google.com
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/149714
git-svn-id: http://src.chromium.org/svn/trunk/src/build@21252 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
* Make processes dumpable when they crash.
* Find crashing processes by searching for a socket inode, rather
than relying on SCM_CREDENTIALS. The kernel doesn't translate PIDs
between PID namespaces with SCM_CREDENTIALS, so we can't use the
PID there.
* Use a command line flag to the renderer to enable crash dumping.
Previously it tried to access the user's home directory for this
information.
* Search for a sandbox helper binary and, if found, use it.
* Include the source for a sandbox helper binary. It's currently not
built by default.
http://codereview.chromium.org/149230
R=evan,markus
BUG=8081
git-svn-id: http://src.chromium.org/svn/trunk/src/build@20110 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
thestig@chromium.org
sgk@google.com
bradnelson@chromium.org
thomasvl@chromium.org
mmoss@chromium.org
dkegel@google.com
mark@chromium.org
phajdan.jr@chromium.org
huanr@chromium.org
aa@chromium.org
dank@chromium.org
deanm@chromium.org
evan@chromium.org
dpranke@google.com
agl@chromium.org
sra@google.com
brettw@chromium.org
jrg@chromium.org