Turn on use_cups for the Mac, add in the required library, and tweak the code
to get it linking. There is still more work to do; this is just a gyp-oriented
change to get things started.
BUG=none
TEST=All targets still build on all platforms.
Review URL: http://codereview.chromium.org/4167006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@64441 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is early in-progress implementation, no cert handling supported. So only available under a build-time flag. (GYP_DEFINES="'use_openssl=1'")
Adds a new build dependency for system OpenSSL libraries, and a new USE_OPENSSL define. Eventually this will disable USE_NSS but for now the two coexist.
BUG=none
TEST=build with use_openssl=1. Goto some https:// pages.
Review URL: http://codereview.chromium.org/3495005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@60936 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
To build, set the clang=1 gyp_define.
This patch is the culmination of many months of effort and many
patches. It contains the minimal changes to Chrome that
are Clang-specific.
With this, I can build the "chrome" target. Once this patch
is in, we can incrementally fix bits of Chrome and various
tests and remove the Clang-specific workarounds.
Review URL: http://codereview.chromium.org/522020
git-svn-id: http://src.chromium.org/svn/trunk/src/build@59882 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Add 'fa' entry to all the grd files.
For *locale_settings*, create new xtb files for Farsi (copied from Arabic).
Also, pulls in ICU @r=58904 (with Farsi data).
locale_settings_fa.xtb has a lot of UI dimensions that may not work
well in Farsi. We need LQA to take a look at them.
terms_FOO.html is not yet available for Farsi as well as Amharic and Swahili. Tentatively, use
terms_en.html.
BUG=45505
TEST='chrome --lang=fa' on Windows should bring up Chrome in Farsi. 'LANGUAGE=fa chrome' should do the same on Linux. (on Ubuntu, 'language-pack-gnome-fa' and 'language-pack-fa' have be installed to get Chrome in Farsi with the UI mirrored).
Review URL: http://codereview.chromium.org/3296013
git-svn-id: http://src.chromium.org/svn/trunk/src/build@58998 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Add the policy templates generated from chrome/app/policy_templates.json to the Mac application bundle. (The template generator for Mac is implemented in CL 3116027) Also remove the old manifest file and references to translations that are not there yet.
The problem with the previous landing attempt was that in Release mode build, the following script was looking for binary files that were not there: build/mac/strip_from_xcode
BUG=49316
TEST=add Chromium to the managed applications' list in the OSX Workgroup Manager, and see if it shows the manageable preferences with English descriptions
Review URL: http://codereview.chromium.org/3287003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@58366 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
heap leak checker to unwind the memory allocation stacks better.
Currently, if a memory region is allocated from a library built without frame
pointers heapchecker is unable to unwind the stack and records only the top
frame. This is inconvenient, because:
-- several leaks from different places are treated as leaks from the same
source
-- it's hard to suppress such leaks, because a one-line suppression is
uninformative
linux_shadow_stacks.cc keeps the threads' IP and SP values in thread-local
stacks upon each function entry/exit using gcc function instrumentation
(-finstrument-functions).
The GetStackTrace routine from stacktrace_shadow-inl.h unwinds the stack as
usual (using frame pointers), but then updates the result with the shadow stack
frames which SP values are below the bottom frame of the unwind result.
Note that -finstrument-functions affects only Chromium code, not the libraries.
This means that we cannot get more than one library function frame at the top
of the stack.
For example, consider a libfoo library that has a public foo_do_something()
routine which allocates memory via foo_alloc(). If Chromium calls
foo_do_something() from ChromeCallFoo(), then the following call chain
effectively happens:
main -> ChromeCallFoo -> foo_do_something -> foo_alloc
If libfoo is built with -fomit-frame-pointers, heapcheck can unwind only the
last stack frame:
foo_alloc
On the other hand, the shadow stack at the allocation site contains everything
below the libfoo calls:
main -> ChromeCallFoo
As a result the following allocation stack is recorded:
main -> ChromeCallFoo -> foo_alloc
This is enough to distinguish between e.g. ChromeCallFoo1 and ChromeCallFoo2
Review URL: http://codereview.chromium.org/3120017
git-svn-id: http://src.chromium.org/svn/trunk/src/build@57658 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
For example, there are differences between unit_tests and browser_tests,
which cause ridiculous problems when moving a test between those.
We're using the symbols anyway, so let's centralize it for maintainability.
TEST=compile
BUG=none
Review URL: http://codereview.chromium.org/3173044
git-svn-id: http://src.chromium.org/svn/trunk/src/build@57555 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Having -rdynamic breaks some plugins since it exports more symbols into
the dynamic symbol table than wanted. In particular, this breaks users of
ppapi's C++ wrappers. It was added to make StaceTraces resolve to symbols
on linux. But now we use the symbolize library from glog so it isn't needed
anymore.
BUG=52105
TEST=Compiles and StackTrace.* test in base_unittests will work.
Review URL: http://codereview.chromium.org/3119033
git-svn-id: http://src.chromium.org/svn/trunk/src/build@56924 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
chrome: create an option for using libcros provided by the system; fix all
includes referring to libcros to not include third_party/
* Headers fix is needed to support using system libcros (installed to /usr/include)
* All includes are "", and therefore a local variant in third_party/cros/ is
always preferred, but system will also get picked up as a secondary target
* Fixed chrome/browser/chromeos/cros/synaptics_library.h comments to better
reflect the header placement
* Added a variable system_libcros defaulting to 0
* Gotten rid of duplicate cros_api.gyp
* Changed both places to either link against cros_api or libcrosapi
TEST=build in the following scenarios:
1) libcros not installed, libcros sources in third_party/, !defined system_libcros
- sucess
2) installed libcros, put #error into /usr/include/cros/chromeos_cros_api.h, repeat 1)
- success
3) BUILD_DEFINES+=system_libcros=1, removed libcros from third_party, repeat 2)
- fail (on #error in chromeos_cros_api.h)
4) Installed clean libcros, repeat 3)
- success
Review URL: http://codereview.chromium.org/3043010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@53288 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Defined TOUCH_UI flag to wrap touch-related code
Added a gyp flag touchui that enables a TOUCH_UI cpp define to wrap
forthcoming touch-related code.
BUG=NONE
TEST=Compiled with and without touchui set via include.gypi
Review URL: http://codereview.chromium.org/3026001
git-svn-id: http://src.chromium.org/svn/trunk/src/build@52551 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Add in two extra libraries needed for building Chromium-for-Chromium OS on a fresh install Ubuntu Lucid 64-bit. Also, start checking for header differences between the 32-bit and 64-bit packages, adding those headers into the 32-bit cons'ed up package install (on Lucid Lynx, the current libcurl4-gnutls-dev package needs this). Clean up any leftover symbolic links that point nowhere. Also take any declared package conflicts and remove them from the Provides line to allow the cons'ed up package to always install (the package derived from libcurl4-gnutls-dev).
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/2865032
git-svn-id: http://src.chromium.org/svn/trunk/src/build@51863 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
points to avoid the need to link against opengl32.lib. Added
_ATL_NO_OPENGL #define in build/common.gypi to prevent link directive
from forcibly pulling in opengl32.lib for any Chrome code using ATL.
Once upstream code in WebKit is changed to use the new wglew entry
points and remove opengl32.lib from the link line, chrome.dll will no
longer depend on opengl32.dll.
BUG=45586
TEST=ran WebGL with --in-process-webgl
Review URL: http://codereview.chromium.org/2856022
git-svn-id: http://src.chromium.org/svn/trunk/src/build@51277 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Eat middle-mouse clicks on the omnibox to avoid tripping a CRichEditCtrl bug.
Original patch by Jared Wein (see http://codereview.chromium.org/2241003 ), r=me.
BUG=6873, 30134
TEST=Middle-click the omnibox, then try to click it (or any other UI element), and make sure the click has an effect. Select a portion of the URL and right-click on the omnibox. Notice that the selection does not change. Clear the selection and right-click on the omnibox and notice that the URL is automatically selected.
git-svn-id: http://src.chromium.org/svn/trunk/src/build@50420 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
1. multi_dll_build: whether or not to build multi dll version.
2. component: used for library that can be built as DLL.
component is set to shared_library if multi_dll_build==1,
in other cases, it is set to "<(library)".
-. Fix win_use_allocator_shim comments and some MSVCRT related settings.
Note: this patch just adds new variables. They are not ready to use yet.
R=darin
BUG=46311
TEST=none
Review URL: http://codereview.chromium.org/2836013
git-svn-id: http://src.chromium.org/svn/trunk/src/build@50362 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Set chromoting to be built by default. Also defines a ENABLE_CHROMOTING flag
if chromoting is enabled in the build system so we can exclude chromoting
if we don't want chromoting code to be linked in.
Review URL: http://codereview.chromium.org/2788003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@49482 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Python script to generate code to dynamically bind to GL functions (native GL, OSMesa, EGL or mock GL for unit tests). This replaces GLEW because GLEW doesn't bind to the GLES dialect of GL.
Moved the mock GL code into app/gfx/gl.
Updated the GPU code and AcceleratedSurface to use the new GL bindings.
TEST=trybots
BUG=none
Review URL: http://codereview.chromium.org/2134006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@49332 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This reverts commit 161f7fd3bdd425167af9fe26fdc5373a2ff44c98.
Revert "Missed a file as part of checkin for r48186"
This reverts commit cff86beba5938209393a6c3bccced62a7f3ff36b.
Revert "Enable warning 4389 as an error on windows builds. This will make"
This reverts commit c78936bcfc65b98edf288191d927a495b0364621.
TBR=mbelshe
Review URL: http://codereview.chromium.org/2253001
git-svn-id: http://src.chromium.org/svn/trunk/src/build@48238 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Seems like some of test binaries are now big enough that gold cannot link with gc-sectinos.
This CL add gyp variable to turn it off. I'll add this flag to master.cfg in separate CL.
BUG=44241
TEST=chromeos valgrind bot should be able to link test binaries.
Review URL: http://codereview.chromium.org/2112004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@47351 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This makes it so toolkit_views==1 is always true for views builds,
either on Windows or ChromeOS.
Three levels of nesting are needed for this chained conditional:
1) Set the default value of ChromeOS.
2) Depending on ChromeOS value, set the default value of toolkit_views.
3) Depending on toolkit_views value, set the rest of the build variables.
This should have no affect on the build, but will allow subsequent cleanup.
Review URL: http://codereview.chromium.org/1799002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@45639 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
- makes device contexts opaque to the plugin
- can get / set multiple attributes and flush with a single call (and underlying IPC message exchange)
- currently works in parallel with old API
- adapted pepper test plugin to use new API if use_new_npdevice_api=1
TEST=trybots, visual confirmation that pepper test plugin works with new API
BUG=none
Review URL: http://codereview.chromium.org/1529005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@44840 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
It seems the best way to keep the seccomp sandbox working is to have
everyone's development environment have it on by default. So we turn
on the seccomp sandbox, but only for non-official builds.
If the build-time flag is set: --disable-seccomp-sandbox turns it off.
If the build-time flag is *not* set: --enable-seccomp-sandbox turns it on.
BUG=36133
Review URL: http://codereview.chromium.org/1558003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@43122 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is a followup to an earlier change (r38266) which did most of the
warning-related cleanup. This one just flips the flag, and fixes some
new warnings that crept in during the window while the flag was off.
Second try, now with some libpng fixes.
BUG=34160
Review URL: http://codereview.chromium.org/1320011
git-svn-id: http://src.chromium.org/svn/trunk/src/build@42700 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is a followup to an earlier change (r38266) which did most of the
warning-related cleanup. This one just flips the flag, and fixes some
new warnings that crept in during the window while the flag was off.
BUG=34160
Review URL: http://codereview.chromium.org/597023
git-svn-id: http://src.chromium.org/svn/trunk/src/build@42688 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
For ffmpeg, I copied the "arm" configs (which include neon) into "arm-neon" configs, and changed HAVE_NEON=1 to 0 in the existing ones. Also, I removed the explicit cflags in ffmpeg.gyp since they are already set in common.gypi
Review URL: http://codereview.chromium.org/660067
git-svn-id: http://src.chromium.org/svn/trunk/src/build@40163 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
file scope.
This extends r38519, which was incomplete.
To resolve bug 33186, I am trying to turn test_shell.gyp into test_shell.gypi,
and have webkit.gyp include it. webkit.gyp is not chromium_code, but the
targets in test_shell.gypi are.
BUG=33186
TEST=builds still work, -Werror and friends are still applied (or not)
correctly
Review URL: http://codereview.chromium.org/600047
git-svn-id: http://src.chromium.org/svn/trunk/src/build@38658 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
file scope.
To resolve bug 33186, I am trying to turn test_shell.gyp into test_shell.gypi,
and have webkit.gyp include it. webkit.gyp is not chromium_code, but the
targets in test_shell.gypi are.
BUG=33186
TEST=builds still work, -Werror and friends are still applied (or not) correctly
Review URL: http://codereview.chromium.org/595010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@38519 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Initial port of GPU process / plugin to Mac OS X. Uses new IOSurface
APIs and therefore currently runs only on 10.6. Alternate strategy
will need to be devised for 10.5.
Slight UI issues remain such as GPU plugins initially showing up in
the wrong place on the page. These will be fixed in follow-on bugs.
Minimal changes made to command buffer code to get it to compile on
Mac OS X. Commented out use of nested anonymous namespaces in
gles2_cmd_decoder.cc which were causing the linker to crash with a seg
fault.
Refactored gyp files so the OS test enabling the GPU plugin is in one
place, common.gypi, and other files test only the variable enable_gpu.
Slight change to gles2_demo_cc.cc to add some simple animation to
verify that updates from the GPU plugin are reaching the screen.
Changed Pepper test plugin to use 3D view by default and commented out
use of audio context because of recent issues.
TEST=none (ran Pepper Test Plugin with 3D view enabled)
BUG=http://crbug.com/25988
Review URL: http://codereview.chromium.org/558035
git-svn-id: http://src.chromium.org/svn/trunk/src/build@37934 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
build/common.gypi has some general patterns for filenames on platforms,
e.g. "don't build _win.cc on non-Windows", so we don't need to duplicate
them here.
While I'm at it, add the FreeBSD/OpenBSD tests as well, since
that was what prompted this change.
Review URL: http://codereview.chromium.org/558034
git-svn-id: http://src.chromium.org/svn/trunk/src/build@37553 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
This will turn on -fno-strict-aliasing. There are regular aliasing problems
in the codebase and at least one of these was not caught by -Wall -Werror
so defaulting to -fno-strict-aliasing seems like a good idea especially
given the increased popularity of gcc 4.4 with it's use in karmic, fedora and in
chromeos chroot builds et. al.
The long term plan is to have some test infrastructure in place that will test
4.4 binaries and to fix the aliasing issues.
BUG=28749
Review URL: http://codereview.chromium.org/519034
git-svn-id: http://src.chromium.org/svn/trunk/src/build@36151 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
This CL is required for supporting Native Client on 64bit Windows. On Win64 we will use a 64bit executable to load NaCl modules. Since we have only one version of Chrome on Windows, this executable has to be built together with 32bit Chrome binaries.
For the targets that are required for both 32bit and 64bit builds, this CL moves the shared parts of the target definitions into targetspecific gypi files (such as base.gypi). New 64bit only targets are added. Since we would like to port as few code as possible at this point, some 64bit targets include less source files or less dependencies than the original 32bit targets. These targets will have nacl_win64 in their name to emphasize that they should be used for NaCl only. Some 64bit targets are identical to the 32bit targets in everything except for the target platform these will have only win64 in their name.
TEST=none
BUG=28176
Review URL: http://codereview.chromium.org/384068TBR=gregoryd@google.com
Review URL: http://codereview.chromium.org/501125
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34990 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This CL is required for supporting Native Client on 64-bit Windows. On Win64 we will use a 64-bit executable to load NaCl modules. Since we have only one version of Chrome on Windows, this executable has to be built together with 32-bit Chrome binaries.
For the targets that are required for both 32-bit and 64-bit builds, this CL moves the shared parts of the target definitions into target-specific gypi files (such as base.gypi). New 64-bit only targets are added. Since we would like to port as few code as possible at this point, some 64-bit targets include less source files or less dependencies than the original 32-bit targets. These targets will have nacl_win64 in their name - to emphasize that they should be used for NaCl only. Some 64-bit targets are identical to the 32-bit targets in everything except for the target platform - these will have only win64 in their name.
TEST=none
BUG=28176
Review URL: http://codereview.chromium.org/384068
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34983 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
timurrrr@chromium.org
mirandac@chromium.org
maruel@chromium.org
scottbyer@google.com
scottbyer@chromium.org
vangelis@chromium.org
evan@chromium.org
thestig@chromium.org
cbentzel@chromium.org
nsylvain@google.com
hans@chromium.org
thakis@chromium.org
bulach@chromium.org
joth@chromium.org
phajdan.jr@chromium.org
jshin@chromium.org
gfeher@chromium.org
pmehta@chromium.org
glider@chromium.org
ajwong@chromium.org
nirnimesh@chromium.org
sky@chromium.org
zelidrag@chromium.org
kbr@google.com
ben@chromium.org
piman@chromium.org
pkasting@chromium.org
victorw@chromium.org
thomasvl@chromium.org
hclam@chromium.org
jam@chromium.org
mdm@chromium.org
apatrick@chromium.org
sergeyu@chromium.org
mbelshe@chromium.org
rafaelw@chromium.org
oshima@chromium.org
scherkus@chromium.org
mad@google.com
tony@chromium.org
willchan@chromium.org
fbarchard@chromium.org
rsesek@chromium.org
mark@chromium.org
alokp@chromium.org
laforge@chromium.org
pvalchev@google.com
kuchhal@chromium.org
robertshield@chromium.org
craig.schlenter@chromium.org
bradnelson@google.com
jrg@chromium.org
apatrick@google.com
gregoryd@google.com
slightlyoff@chromium.org
benl@chromium.org