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
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
Previously we built our own copies of many common system libraries.
This comes from our Windows history, where these libraries have to be
carried by any application using them because they aren't provided as
standard.
On Linux, however, they are ubiqutous so we can save binary size by
dynamically linking against the system versions.
TEST=none
BUG=29738
http://codereview.chromium.org/465126
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34084 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
This makes backtraces again include symbols in Debug builds.
TEST=StackTrace.OutputToStream (in a Debug build; the test is
already disabled in Release builds, exactly because this flag
breaks the thing the test is testing.)
Review URL: http://codereview.chromium.org/457006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@33320 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The concept of "ticket promotion" is added to the application when Keystone is
in use. Ticket promotion is used to turn a user Keystone ticket, which Chrome
normally establishes when it launches, into a system Keystone ticket, after
successful user authentication and authorization. Having a system Keystone
with a system ticket means that updates are applied with root privileges
instead of user privileges, essentially eliminating the possibility that a
user will fall off of the auto-update train because they can read and execute
but not write the application.
Two principles of promotion apply:
- An application on a user ticket NEEDS promotion if it determines that it
doesn't have permission to write to itself. Being on a user ticket, an
update attempt would fail.
- An application on a user ticket WANTS promotion if it already NEEDS
promotion. Additionally, if it is installed in a system-wide location
such as /Applications, it will WANT promotion, even if it does not NEED it.
If promotion is needed, an info bar will show up on launch requesting it.
This info bar works similarly to the default browser info bar: it has a "don't
bother me again" button, it will only show up after the first launch, it won't
disappear on navigation if the navigation happens very quickly, and it won't
show itself if another info bar is up. This means that if both the default
browser info bar and the promotion info bar have a shot at showing, only one
will win. In my experience, each wins about half of the time.
If promotion is needed, the update UI in the About window will be hidden.
Checking for updates and offering to apply them doesn't make much sense when
the update won't be able to install successfully. All of the auto-update
machinery is still working in the background, but the About window UI is
hidden.
If promotion is wanted, the About window will contain a new button allowing
the user to enter promotion. This gives access to the same promotion routine
as the promotion info bar. It can be used even from an administrative account
that is able to update the application without promotion. It's intended to be
used by the system administrator of the family without requiring them to
switch to one of the kids' accounts.
BUG=16360
TEST=Exhaustively, please.
Review URL: http://codereview.chromium.org/437053
git-svn-id: http://src.chromium.org/svn/trunk/src/build@33241 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Rather than duplicate logic in the tree, merge all of the
shared rules about patterns in filenames into one common set.
The pattern is: "if (OS != x): exclude x's files."
This is especially needed for upcoming changes that bring in a few
more platform-specific (FreeBSD, OpenBSD, Solaris(?)) files.
Review URL: http://codereview.chromium.org/443011
git-svn-id: http://src.chromium.org/svn/trunk/src/build@33160 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This change also reworks the tcmalloc dependency to be added only to chrome and test_shell, instead of base. This is necessary since otherwise tcmalloc will be double initialized (by both the main executable and dlopen'd shared objects like the npapitestplugin.so).
Add valgrind suppressions. This are invalid reads on static initialization in the VDSOSupport module. I haven't investigated it yet, but I suspect they're benign.
BUG=http://crbug.com/28149, http://crbug.com/28385
Review URL: http://codereview.chromium.org/399081
git-svn-id: http://src.chromium.org/svn/trunk/src/build@33010 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
We have compile flags set up to support using --gc-sections, but apparently
we aren't using it for the actual link! It was probably lost during the gyp
conversion.
This has a few-megabyte difference on binary size.
(Trying submit again, hopefully thestig successfully converted bots...)
Review URL: http://codereview.chromium.org/399048
git-svn-id: http://src.chromium.org/svn/trunk/src/build@32330 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
eh_frame is data used for exception frames. We already disable exceptions,
but it turns out this obscure extra flag was responsible for the eh_frame
making it into our binaries.
This shaves off another few megabytes from our binaries.
Review URL: http://codereview.chromium.org/397032
git-svn-id: http://src.chromium.org/svn/trunk/src/build@32254 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Requires compiling with linux_use_tcmalloc=1.
When enabled by --heap-profiler flag in test_shell exposes
chromium.HeapProfiler object to JavaScript. The object has three
methods:
o start() -- starts profiling
o dump() -- dumps data accumulated since start() to file
named like chromium-YYYY-MM-DD-TS.heap
o stop() -- stops profiling.
Output can be analyzed by third_party/tcmalloc/tcmalloc/src/pprof.
For example:
$ third_party/tcmalloc/tcmalloc/src/pprof \
sconsbuild/Release/test_shell \
chromium-2009-11-06-1234567890.heap
See http://code.google.com/p/google-perftools/ for details on how to
use pprof.
Patch contributed by vitalyr@chromium.org. Original review at
http://codereview.chromium.org/377010/show.
TBR=vitalyr
Review URL: http://codereview.chromium.org/390015
git-svn-id: http://src.chromium.org/svn/trunk/src/build@31688 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
target_defaults. This is equivalent to how Xcode sets SDKROOT from the
Project Info window's General tab. Making this setting project-wide means
that the selected SDK will show up properly in that UI.
BUG=26976
TEST=Build still works.
SDK (typically "Mac OS X 10.5") shows up in Project Info:General.
Review URL: http://codereview.chromium.org/371035
git-svn-id: http://src.chromium.org/svn/trunk/src/build@31307 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The motivation is that this removes the sync IPC on every call to the spellchecker. Also, currently we spellcheck in the IO thread, which frequently needs to go to disk (in particular, the entire spellcheck dictionary starts paged out), so this will block just the single renderer when that happens, rather than the whole IO thread.
This breaks the SpellChecker class into two new classes.
1) On the browser side, we have SpellCheckHost. This class handles browser-wide tasks, such as keeping the custom words list in sync with the on-disk custom words dictionary, downloading missing dictionaries, etc. On Posix, it also opens the bdic file since the renderer isn't allowed to open files. SpellCheckHost is created and destroyed on the UI thread. It is initialized on the file thread.
2) On the renderer side, SpellChecker2. This class will one day be renamed SpellChecker. It handles actual checking of the words, memory maps the dictionary file, loads hunspell, etc. There is one SpellChecker2 per RenderThread (hence one per render process).
My intention is for this patch to move Linux to this new approach, and follow up with ports for Windows (which will involve passing a dictionary file name rather than a file descriptor through to the renderer) and Mac (which will involve adding sync ViewHost IPC callsfor when the platform spellchecker is enabled). Note that anyone using the platform spellchecker rather than Hunspell will get no benefit out of this refactor.
There should be no loss of functionality for Linux (or any other platform) in this patch. The following should all still work:
- dictionary is loaded lazily
- hunspell is initialized lazily, per renderer
- language changes work.
- Dynamic downloading of new dictionaries
- auto spell correct works (as well as toggling it).
- disabling spellcheck works.
- custom words work (including adding in one renderer and immediately having it take effect in other renderers, for certain values of "immediate")
TODO:
- move spellchecker unit tests to test SpellCheck2
- add sync IPC for platform spellchecker; port to Mac
- add dictionary location fallback; port to Windows
- remove SpellChecker classes from browser/
BUG=25677
Review URL: http://codereview.chromium.org/357003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@31199 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
- only include cflags/linkflags and other compiler settings that are target-specific when building for 'target'
- make build tools (protoc) compile for 'host', and change the dependencies on them to reflect that.
Review URL: http://codereview.chromium.org/265031
git-svn-id: http://src.chromium.org/svn/trunk/src/build@30381 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
widget_gtk when building chromeos build. We need a #ifdef for
CHROMEOS but not using TOOLKIT_VIEWs for the browser window. I'm
temporarily adding this one.
This bug is the result of Oshima making TOOLKIT_VIEWS set OS_CHROMEOS.
Review URL: http://codereview.chromium.org/270092
git-svn-id: http://src.chromium.org/svn/trunk/src/build@28916 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
* changed gyp files so that all files compiled for chrome os will be also compiled when toolkit_views==1
* changed to define OS_CHROMEOS when toolkit_views==1
* changed TabOverbiewMessageListener to use BrowserView instead of BrowserWindowGtk when toolkit_views==1
I left one for CHROME_NOTIFY_FLOATING_TAB_OVER_TOPLEVEL b/c i couldn't figure out how to get gdkwindow
from xid. Looks like I need to register it somewhere
Note: Nicolas updated trybot and buildbot to include chromeos dependency, so this all should compile fine.
BUG=none
TEST=run views unit test and browser.
Review URL: http://codereview.chromium.org/262027
git-svn-id: http://src.chromium.org/svn/trunk/src/build@28764 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
into the gfx namespace.
Combine the PNGEncoder and PNGDecoder. There were separate when we had
different executables for the browser and renderer, and linked the encoder only
in one of them (which saved us some space used by libpng). This hasn't been the
case for years, so combining them (again) makes sense.
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/243076
git-svn-id: http://src.chromium.org/svn/trunk/src/build@27930 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
1. Downstreamed building webkit/extension/v8/*.cc files, which were built by upstream webcore by mistake. Now glue will build them.
I tested that even though webcore still builds them, there are no errors if glue also builds them.
2. Added webkit_chromium_port variable to build/common.gypi which is turned off by default. Currently, nothing uses it but the chrome port will need it.
Review URL: http://codereview.chromium.org/220026
git-svn-id: http://src.chromium.org/svn/trunk/src/build@27122 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Default to Title Case strings for Mac and Linux/GTK.
Pass an extra define to the invoke of grit for TitleCase strings.
Test the define for grit Title Case strings and have two sets of strings where needed.
DEPs roll to pick up a new GYP that will keep int values as ints.
BUG=22253
TEST=The bookmark bar menus on Mac and linux gtk will be Title Case, in Windows and ChromeOS they will be Sentence case. NOTE: we'll the translations in the Title Case areas until new translations are entered.
Review URL: http://codereview.chromium.org/210022
git-svn-id: http://src.chromium.org/svn/trunk/src/build@26803 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
Add "support_macosx_10_4" option to common.gypi that causes it to change deployment target, and define a new preprocessor symbol on the Mac build. Setting this flag to true is harmless on non Mac builds and has no effect.
Make various changes to source files where they modify their behavior in the presence of the new preprocessor symbol to become 10.4 compatible.
Review URL: http://codereview.chromium.org/201122
git-svn-id: http://src.chromium.org/svn/trunk/src/build@26285 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This patch adds support for a selinux GYP variable which, when set to
one, does the following:
* Removes the seccomp sandbox from the compile
* Removes support for SUID sandboxing from the zygote
* Performs a dynamic transition, in the zygote, to
chromium_renderer_t.
This code requires that the system policy have a sensible set of
access vectors for the chromium_renderer_t type. Such a policy will be
found in sandbox/selinux in the future.
http://codereview.chromium.org/203071
git-svn-id: http://src.chromium.org/svn/trunk/src/build@26257 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
this just generalizes it to debug_ and to mac.
Required a litle rearranging. Tested by comparing
xcode and make files before and after change.
Ignores those settings when generating Visual C++ projects,
but since the goal was to let valgrind bots tweak
optimization settings, that's ok for now.
Review URL: http://codereview.chromium.org/202054
git-svn-id: http://src.chromium.org/svn/trunk/src/build@25997 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This CL adds support for a 'sysroot' GYP define, that should point to the target root filesystem for cross-compilation.
It passes that argument to the compiler and linker which uses it to prefix its hard-coded path (e.g. /usr/include)
It also points pkg-config to look for package configs there, and rewrite the paths to be prefixed by 'sysroot' (since pkg-config doesn't do it itself)
Review URL: http://codereview.chromium.org/199016
git-svn-id: http://src.chromium.org/svn/trunk/src/build@25418 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
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
ben@chromium.org
piman@chromium.org
pkasting@chromium.org
victorw@chromium.org
thomasvl@chromium.org
thakis@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
timurrrr@chromium.org
scherkus@chromium.org
mad@google.com
tony@chromium.org
evan@chromium.org
willchan@chromium.org
glider@chromium.org
fbarchard@chromium.org
thestig@chromium.org
jshin@chromium.org
rsesek@chromium.org
zelidrag@chromium.org
mark@chromium.org
alokp@chromium.org
kbr@google.com
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
mmoss@google.com
sehr@google.com
agl@chromium.org
joel@chromium.org
dank@chromium.org
mmoss@chromium.org
estade@chromium.org
idana@chromium.org
huanr@chromium.org
bradnelson@chromium.org
brettw@chromium.org
ajwong@chromium.org
sky@chromium.org
sgk@google.com
maruel@chromium.org
yaar@chromium.org
maf@google.com
dkegel@google.com
yutak@chromium.org
munjal@chromium.org
darin@chromium.org