- that is, defining use_openssl=1 will now remove all dependency on NSS.
This does not impact any of the standard, non-openssl builds.
Adds stub implementations of several files that need to be fully implemented in follow up patchs.
Firefox import code will need some more substatial refactoring, as it makes little sense to be
attempting a firefox import without NSS libraries to hand, however the UI etc has numerous assumption
about the presence of this importer.
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/3855004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@63506 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This includes the ui_tests, all the tests previously built by ThreadSanitizer
Mac bot (see the 'chromium_builder_dbg_mac_tsan' target) and all the tests
previously built by Memcheck Mac bot (see
buildbot/master.chromium.memory/master.cfg)
Review URL: http://codereview.chromium.org/3135020
git-svn-id: http://src.chromium.org/svn/trunk/src/build@56509 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is so ANGLE will find it.
Also added ANGLE as a Chrome dependency.
There must be a better way to detect whether there is a directxsdk directory in third_party. I'm open to ideas.
TEST=try, check d3dx9 is copied to product dir when building chrome, check ANGLE initializes
BUG=45898
Review URL: http://codereview.chromium.org/2843060TBR=apatrick@chromium.org
git-svn-id: http://src.chromium.org/svn/trunk/src/build@53079 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is so ANGLE will find it.
Also added ANGLE as a Chrome dependency.
There must be a better way to detect whether there is a directxsdk directory in third_party. I'm open to ideas.
TEST=try, check d3dx9 is copied to product dir when building chrome, check ANGLE initializes
BUG=45898
Review URL: http://codereview.chromium.org/2843060
git-svn-id: http://src.chromium.org/svn/trunk/src/build@53076 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In order to pass the check dependency step in the build, I added rlz to
the include_rules in DEPS. However, I am not sure this is the best solution.
TEST=Make sure that the RLZ pings from chrome are the sameas they were with
the old RLZ dll
BUG=none
Review URL: http://codereview.chromium.org/2755002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@49399 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
WebKit DumpRenderTree.
The following code change affects only WebKit DumpRenderTree.
* webkit_support.cc
- WebPluginImplWithPageDelegate passes a plugin path and MIME type to WebPluginImpl.
- CreateWebPlugin checks a MIME type.
This is the same logic as test_shell.
* test_webplugin_page_delegate.h
Creates and returns a WebPluginDelegateImpl instance.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/2729004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@49372 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
on this project; its only purpose is to copy the rlz.dll file to the correct
spot in the output directory.
This is the first step in getting the new open source RLZ library into
chromium. A following CL will add the calls to new implementation.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/2640003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@49059 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
SSLClientSocketMac. Specify the --use-nss-for-ssl command-line
option to use SSLClientSocketNSS.
The nss.gyp in src/net/third_party/nss is renamed ssl.gyp to avoid
a naming conflict with the nss.gyp in src/third_party/nss. The
GYP generator for Xcode project files disallows same-named .gyp files.
SSL client authentication doesn't work yet.
R=mark
BUG=30689
TEST=No build and test failures on Mac and Windows.
Review URL: http://codereview.chromium.org/2322008
git-svn-id: http://src.chromium.org/svn/trunk/src/build@48650 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The problem was the circular gyp dependency between webkit.gyp
and WebKit.gyp:
webkit.gyp:pull_in_webkit_unit_tests -> WebKit.gyp -> webkit.gyp:webkit_support.
The fix is to move webkit_support into its own gyp file (like we do
in an webkit only checkout). We can't use the same gyp file for in-
chromium and in-webkit because we need to change the include path for
features.gypi. In gyp, variable expansion happens after includes
(otherwise you'd have to expand variables twice and they could change
values), so we can't use a single gyp file for this.
Review URL: http://codereview.chromium.org/1995013
git-svn-id: http://src.chromium.org/svn/trunk/src/build@47012 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is a software GL renderer that can be used by bots that do not have access to native GL. It will be used for running tests that use GL, such as Pepper 3D, WebGL and accelerated compositing. Only working on Windows so far.
TEST=trybots
BUG=none
Review URL: http://codereview.chromium.org/1740001
git-svn-id: http://src.chromium.org/svn/trunk/src/build@45241 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The scons generator currently does not correctly handle the case in which you
have a target with no sources (for instance all the mock targets used for the
bots). So far this has not been an issue because these mock targets were only
used for Windows and Mac. jiesun's recent addition of a chromeos_builder target
caused this issue to manifest itself.
BUG=None
TEST=None
TBR=jiesuN
Review URL: http://codereview.chromium.org/661249
git-svn-id: http://src.chromium.org/svn/trunk/src/build@40229 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
test_shell.gyp. This allows the removal of webkit.gyp:pull_in_test_shell,
eliminating the circular relationship between webkit.gyp and test_shell.gyp.
The expected semantics of building all of test_shell during a webkit.gyp:All
build is performed are retained.
This change depends on GYP r781 (in Chromium at r38526) for GYP suffix
operator path section treatment. It also depends on Chromium r38519 and
r38658 for common.gypi treatment of chromium_code.
BUG=33186
TEST=Xcode no longer holds stale project files in memory
Review URL: http://codereview.chromium.org/602006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@38664 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Turned out there is no benefit of having this in a separate git repository.
No code change in candidate_window.cc, but modified the copyright notice
from Chromium OS Authors to Chromium Authors.
Slightly modified text_input.gyp to make it compile.
We'll also change cros_deps/DEPS in a separate CL.
BUG=none
TEST=confirmed candidate_window compiles as before.
Review URL: http://codereview.chromium.org/579026
git-svn-id: http://src.chromium.org/svn/trunk/src/build@38345 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Port back CLD to Linux and Mac by replacing Windows API calls with ICU's equivalent APIs for normalization.
I also fixed bug 23553 (Traditional Chinese is not detected) by calling LanguageCode instead of LanguageCode_ISO_639_1. The latter covers only ISO 639-1, but there are languages detected by CLD not covered by ISO 639-1. In that case, ISO 639-2 is used. In case even ISO 639-2 does not cover (e.g. Traditional Chinese), another fallback is taken by LanguageCode.
The html file for CLD testing (french_sentence.html) is explicitly labelled with charset=ISO-8859-1.
Original Review: http://codereview.chromium.org/523108
BUG=25206,23553
TEST=1. CLD is built on Linux/Mac
2. The following test pass:
- unit_tests: Extension*.DetectTabLang* and CompactLangDet*.*
- browser_tests: ExtensionBrowserTest.Toolstrip
3. Install the 'cld extension' in chrome/common/extensions/docs/examples/api/i18n/cld and go to http://news.google.com.tw and 'zh-TW' shows up in the language badge at the upper right (upper-left in he/ar Chrome) corner.
TBR=jcampan
Review URL: http://codereview.chromium.org/545123TBR=jshin@chromium.org
Review URL: http://codereview.chromium.org/551070TBR=jshin@chromium.org
Review URL: http://codereview.chromium.org/549091
git-svn-id: http://src.chromium.org/svn/trunk/src/build@36552 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Also remove the now-unneeded gyp variables 'chrome_frame_define' and 'google_update_appid'.
BUG=Both Chrome and Chrome Frame products should be buildable from a single solution file - we shouldn't need to run GYP with different settings to get a CF solution.
TEST=none
Review URL: http://codereview.chromium.org/542078
git-svn-id: http://src.chromium.org/svn/trunk/src/build@36546 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
1) Rearrange the chrome_frame.gyp file to:
a) Split out most of CF into a static lib to make writing unit tests easier (not having to re-include source files).
b) Remove most of the un-needed xulrunner-sdk includes.
2) Move all OBJECT_ENTRY_AUTO macros to chrome_tab.cc since they don't work without extra work when residing in a lib.
3) Rename npchrome_tab.dll to npchrome_frame.dll.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/523040
git-svn-id: http://src.chromium.org/svn/trunk/src/build@35543 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Added API for managing buffers to Pepper 3D device.
Removed DCHECK from WebPluginImpl::SetWindow that checks against a windowless plugin being given a window handle. Please check this! Now an initially windowless plugin instance gets a handle when it requests a Pepper 3D context. Perhaps the window handle should be concealed from the underlying plugin isntance.
Removed enable_gpu gyp variable and C macro. GPU code is always built on windows but not mac or linux. It is enabled at runtime with the --enable-gpu-plugin switch.
Redesigned CommandBuffer interface so it exposes shared memory through a Buffer. This was necessary because Pepper has no notion of shared memory handles. The Buffer exposes the shared memory as both a handle (through base::SharedMemory) and the mapped address and size.
Refactored CommandBufferEngine so mapped shared memory addresses and sizes are returned with a single call rather than two separate calls.
Added 3D demo to pepper test plugin.
TEST=try servers
BUG=none
Review URL: http://codereview.chromium.org/367002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@35185 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In the previous CL I made the build of pepper_test_plugin conditional
but forgot to remove the unconditional reference, leaving the build breakage
on Linux.
TBR=jrg,asargent,skylined
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/485008
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34232 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
There were problems building Skia and others for the 64-bit linux versions of the
Pepper test plugin, so I have disabled building that plugin except on Windows for now
and added a TODO.
One significant addition to the previous comment lines. The flag enable_gpu=1 now
causes the build definition ENABLE_GPU=1 to allow guarding of dependent code.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/481001
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34227 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is needed because the NaCl plugin code that runs in the renderer
needs to use Pepper APIs all the time, and NaCl support has been enabled
by default for several months now. To cause an untrusted Pepper plugin
to run in the renderer one needs to specify the internalpepper flag.
I have also removed the enable_pepper flag from gyp. As the build of the
GPU process was tied to this flag, I have renamed the flag to enable_gpu.
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/464074TBR=sehr@google.com
Review URL: http://codereview.chromium.org/475004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34162 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is needed because the NaCl plugin code that runs in the renderer
needs to use Pepper APIs all the time, and NaCl support has been enabled
by default for several months now. To cause an untrusted Pepper plugin
to run in the renderer one needs to specify the --internal-pepper flag.
I have also removed the enable_pepper flag from gyp. As the build of the
GPU process was tied to this flag, I have renamed the flag to enable_gpu.
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/464074
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34161 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
(i.e. this is a plain vanilla build used when layers like base/allocator
are getting in the way of debugging)
and make sure they use msvcrt rather than libcmt
(libcmt is used to help shim malloc/free, but it gets
in the way of valgrind doing the same thing).
Sadly, this is now a gyp-time operation rather than a Configuration
option.
Had to remove hardcoded C prototype for _set_new_mode,
as that caused link errors.
Also add variables win_{release,debug}_{Optimization,RuntimeLibrary}
to let the valgrind build override those settings.
Fix calling convention on _set_new_mode to match the
one in <new.h>
BUG=none
TEST=build with ~/.gyp/include.gypi set as described in comment in common.gypi, gclient runhooks, do release build, verify all exe's and dll's linked against msvcrt dll
Review URL: http://codereview.chromium.org/455037
git-svn-id: http://src.chromium.org/svn/trunk/src/build@33719 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
You can switch to using -lOmxCore by setting the gyp variable use_system_openmax=1.
Also fixed type-punning warnings in omx_video_decoder.cc
BUG=28663
TEST=building omx_test should have no linker errors
Review URL: http://codereview.chromium.org/431041
git-svn-id: http://src.chromium.org/svn/trunk/src/build@33012 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
in subtle and devious ways.
Renaming webkit.gyp -> webkit_glue.gyp changed webkit.sln to webkit_glue.sln,
which occured unbeknownst to the builders who continued to build webkit.sln
for most of the day. This wasn't an issue until we did a WebKit roll, where
the trickery was discovered and hell broke loose.
TBR=yaar
TEST=green bots
BUG=none
Review URL: http://codereview.chromium.org/385084
git-svn-id: http://src.chromium.org/svn/trunk/src/build@31887 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This mega patch contains a few simple but tightly dependent changes:
1. Deletion of webkit/api/WebKit.gyp. The file now lives in webkit.org.
2. Rename of webkit/webkit.gyp to webkit/webkit_glue.gyp. Having two webkit.gyp was a source of developer confusion.
3. Gyp dependencies are updated across chromium to point at the upstream WebKit.gyp and the renamed webkit_glue.gyp.
4. Some 200+ files include paths fixed to point to third_party/WebKit/WebKit/chromium instead of webkit/api. The later will be deleted in a subsequent patch.
Review URL: http://codereview.chromium.org/387020
git-svn-id: http://src.chromium.org/svn/trunk/src/build@31749 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
breaking the interactive ui tests. It just needs a clobber.
It looks like 2 parts of the code don't agree on the number of
buttons on the bookmark bar. Maybe because part of the code is
compiled with CHROME_PERSONALIZATION = 1 while the test is compiled
with CHROME_PERSONALIZATION = 0. Maybe this new gyp change broke the
define propagation. This is really easy to replicate, and should also
be easy to debug.
Original Log:
Relanding the interactive UI tests GYP factor out, as it turns
out it is not responsible for breaking the interactive ui tests.
Review URL: http://codereview.chromium.org/271046
git-svn-id: http://src.chromium.org/svn/trunk/src/build@28668 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Why: Simpler build code. If everybody includes it, it should be included automatically.
Why now: The webkit chromium builds need it be specified, since can't default to build/common.gypi.
What was done:
1. build/common.gypi's contents were moved to a new file build/gyp_chromium.gypi
2. tools/gyp/gyp_chromium was moved to build/gyp_chromium and made to automatically include build/gyp_chromium.gypi.
3. lots of gyp files were fixed to not refer to build/common.gypi any more.
4. o3d which also builds independently of chrome, was fixed to have a gyp_o3d that includes gyp_chromium.gypi too.
5. build/common.gypi was left empty, because there are some external projects that still refer to it.
Things that are left to do after this patch is in:
1. The following external files (in other repositories) need to stop include common.gypi
./third_party/hunspell/hunspell.gyp
./third_party/icu/icu.gyp
./v8/tools/gyp/v8.gyp
2. Once nobody refers to common.gypi anymore, delete common.gypi
-or-
Delete gyp_chromium.gypi and move its content back to common.gypi
Tested on mac, win and linux. On win, got a few unit tests errors on chrome bookmarks, which should not be related. I'm running again with clobber to verify.
Review URL: http://codereview.chromium.org/206006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@26302 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Make sure that there are no references to tcmalloc code in the Linux build.
This is part of an attempt to reland r26264.
git-svn-id: http://src.chromium.org/svn/trunk/src/build@26292 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In addition, add a dummy C++ source file (xmldummy_mac.cc) to libxml to work around an Xcode bug (xmllint and xmlcatalog are linked with gcc rather than g++ even though it's linked to a "C++ library", libicuuc.a).
Also updated is the test results for net_util_unittests.
This will not be landed until deps/third_party/icu42 is ready for all 3 platforms (Windows VS build files are not yet updated there).
BUG=8198
TEST=On all platforms, all the targets are built fine.
Review URL: http://codereview.chromium.org/172031
git-svn-id: http://src.chromium.org/svn/trunk/src/build@25708 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
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
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
* 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
brettw@chromium.org
nsylvain@chromium.org
joth@chromium.org
fbarchard@chromium.org
lzheng@chromium.org
glider@chromium.org
apatrick@chromium.org
thakis@chromium.org
timurrrr@chromium.org
pinkerton@chromium.org
robertshield@chromium.org
ajwong@chromium.org
satorux@chromium.org
hclam@chromium.org
rogerta@google.com
tkent@google.com
sergeyu@chromium.org
wtc@chromium.org
cmasone@google.com
tony@chromium.org
willchan@chromium.org
thestig@chromium.org
maruel@chromium.org
pvalchev@google.com
alokp@chromium.org
akalin@chromium.org
sanjeevr@chromium.org
evan@chromium.org
ben@chromium.org
piman@chromium.org
bradnelson@google.com
jiesun@google.com
mark@chromium.org
laforge@chromium.org
jshin@chromium.org
dspringer@google.com
sehr@google.com
arv@chromium.org
rsesek@chromium.org
apatrick@google.com
benl@chromium.org
dank@chromium.org
sgk@chromium.org
scherkus@chromium.org
mmoss@chromium.org
agl@chromium.org
dglazkov@google.com
yusukes@google.com
yaar@chromium.org
jcampan@chromium.org
slightlyoff@chromium.org
sgk@google.com
thomasvl@chromium.org
nick@chromium.org
jam@chromium.org
huanr@chromium.org
dpranke@google.com
sra@google.com
sidchat@google.com