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
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
willchan@chromium.org
mmoss@chromium.org
estade@chromium.org
hclam@chromium.org
evan@chromium.org
idana@chromium.org
huanr@chromium.org
mark@chromium.org
jshin@chromium.org
craig.schlenter@chromium.org
apatrick@google.com
piman@chromium.org
bradnelson@chromium.org
brettw@chromium.org
ajwong@chromium.org
jrg@chromium.org
sky@chromium.org
oshima@chromium.org
sgk@google.com
maruel@chromium.org
thestig@chromium.org
robertshield@chromium.org
yaar@chromium.org
thomasvl@chromium.org
timurrrr@chromium.org
maf@google.com
agl@chromium.org
dkegel@google.com
dank@chromium.org
bradnelson@google.com
yutak@chromium.org
munjal@chromium.org
darin@chromium.org
sidchat@google.com
tim@chromium.org
aa@chromium.org
deanm@chromium.org
nsylvain@chromium.org
sehr@google.com
nick@chromium.org
tc@google.com
ben@chromium.org
dglazkov@chromium.org
awalker@google.com
pinkerton@chromium.org
dimich@google.com