Changes:
1. Consolidate the logic of "ENABLE_MDNS or OS_MACOSX" into a single C++/grit/ninja define called "enable_service_discovery"
2. Move a bunch of files from being conditioned on enable_mdns to being conditioned on enable_service_discovery.
3. Create a separate, simplified PrivetHTTPAsynchronousFactory that synchronously returns a PrivetHTTPClient for the mDNS host and port
without resolving, since on OSX mDNS resolution is baked into the operating system.
BUG=352811
Review URL: https://codereview.chromium.org/195983023
git-svn-id: http://src.chromium.org/svn/trunk/src/build@258480 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is enough for this to work OK:
[gn-2013]d:\src\cr\src>gn gen out_gn
[gn-2013]d:\src\cr\src>ninja -C out_gn gn
[gn-2013]d:\src\cr\src>out_gn\gn gen out_gn2
[gn-2013]d:\src\cr\src>ninja -C out_gn2 gn
...
[297/297] LINK gn.exe
I'm not sure if we need all the deleted stuff for something
else, but I guess we can revive it when we need it.
(There's some dependency problem with linking atm, as
"ninja -C out_gn gn" always relinks, but I think it's unrelated.)
R=brettw@chromium.org
BUG=297677
Review URL: https://codereview.chromium.org/204663004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@258327 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The Android WebView uses the system ICU on target anyway, so this only
affects the host build of ICU used to build the host V8. This means the
flag is now enabled on all platforms by default and no longer needs to
be conditional.
BUG=
Review URL: https://codereview.chromium.org/204783003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@258278 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
- Fix Android lint warning about using the default locale in
BrowserAccessibilityManager.java
- Suppress javac deprecation warning about AbsoluteLayout, which we're
deliberately using and which isn't going away anytime soon.
- Suppress lint warning about using Context.PRINT_SERVICE constant,
which was added in API level 19, since we only create the print
service when API level is >=19.
Review URL: https://codereview.chromium.org/203823005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@258249 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Reason for revert:
Might be the cause for memory exhaustion during compilation on the Linux dbg build bot:
http://build.chromium.org/p/chromium.linux/buildstatus?builder=Linux%20Builder%20%28dbg%29%2832%29&number=21991
Original issue's description:
> Adding -g3 to get macro expansion support. (Default is -g2.)
> Adding -gdwarf-4 for macro expansion support.
>
> * gcc 4.6 outputs DWARF-2 by default
> * gcc 4.7 outputs DWARF-4 by default
> * clang <3.4 outputs DWARF-3 by default
> * clang >3.4 outputs DWARF-4 by default
>
> From http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
> > -g3
> > Level 3 includes extra information, such as all the macro
> > definitions present in the program. Some debuggers support macro
> > expansion when you use -g3.
> >
> > -gdwarf-4
> > Produce debugging information in DWARF format (if that is
> > supported). The value of version may be either 2, 3 or 4; the
> > default version for most targets is 4. Note that with DWARF
> > Version 2, some ports require and always use some non-conflicting
> > DWARF 3 extensions in the unwind tables.
> >
> > Version 4 may require GDB 7.0 and -fvar-tracking-assignments for
> > maximum benefit.
>
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=257944TBR=stuartmorgan@chromium.org,erg@chromium.org,mark@chromium.org,mmoss@chromium.org,thestig@chromium.org,mmoss@google.com,mithro@mithis.com
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/203683007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257959 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Adding -gdwarf-4 for macro expansion support.
* gcc 4.6 outputs DWARF-2 by default
* gcc 4.7 outputs DWARF-4 by default
* clang <3.4 outputs DWARF-3 by default
* clang >3.4 outputs DWARF-4 by default
From http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
> -g3
> Level 3 includes extra information, such as all the macro
> definitions present in the program. Some debuggers support macro
> expansion when you use -g3.
>
> -gdwarf-4
> Produce debugging information in DWARF format (if that is
> supported). The value of version may be either 2, 3 or 4; the
> default version for most targets is 4. Note that with DWARF
> Version 2, some ports require and always use some non-conflicting
> DWARF 3 extensions in the unwind tables.
>
> Version 4 may require GDB 7.0 and -fvar-tracking-assignments for
> maximum benefit.
Review URL: https://codereview.chromium.org/198363002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257944 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
A bunch of mac builder bots are still on 10.6 (http://crbug.com/353529)
> roll clang 198389:202554
>
> This change contains several big changes, many of the caused by upstream
> llvm enabling c++11 in their codebase and thus having higher minimum
> requirements for their toolchain and runtime environment:
>
> * clang on OS X now requires libc++, which means it'll only run on OS X 10.7+,
> so change the deployment target from 10.5 to 10.7 (we were planning on
> requiring 10.8 or 10.9, see bug 335325, but since several people are waiting
> on a new clang, let's go to 10.7 only for now and do more as a follow-up)
> * On OS X, the compiler is only usable with libc++ if libc++ is checked out
> and `make install` is run, so do that for the phase 1 compiler.
> (Chrome doesn't use libc++ yet, so we don't do that for the bootstrapped
> compiler.)
> * clang on linux now needs libstdc++ 4.7+ which isn't present on precise.
> So we now include a newer libstdc++ in the compiler bundle (meaning
> this clang should still run on precise).
> * clang is broken for android at r202554. To unblock oilpan, merge three
> later changes into this roll, llvm r202793, r203601, and r203635
>
> Regular, less tricky clang roll stuff:
> * Disable the new warning -Wabsolute-value for now (crbug.com/351479
> for turning it on)
> * Disable -Wno-tautological-pointer-compare for libxml where it now
> fires.
> * Since this bundles a new version of the oilpan plugin, bump its suffix to _3
> * Change plugin code to track upstream api change
> * Remove plugin flag check-url-directory as that's now always on
>
> Due to the c++11 stuff, it's likely that this change will get reverted a few times.
>
> BUG=351479, 287029,341352,333968,335325
> TBR=hans@chromium.org
>
> Review URL: https://codereview.chromium.org/195623002TBR=thakis@chromium.org
Review URL: https://codereview.chromium.org/203313004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257620 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This change contains several big changes, many of the caused by upstream
llvm enabling c++11 in their codebase and thus having higher minimum
requirements for their toolchain and runtime environment:
* clang on OS X now requires libc++, which means it'll only run on OS X 10.7+,
so change the deployment target from 10.5 to 10.7 (we were planning on
requiring 10.8 or 10.9, see bug 335325, but since several people are waiting
on a new clang, let's go to 10.7 only for now and do more as a follow-up)
* On OS X, the compiler is only usable with libc++ if libc++ is checked out
and `make install` is run, so do that for the phase 1 compiler.
(Chrome doesn't use libc++ yet, so we don't do that for the bootstrapped
compiler.)
* clang on linux now needs libstdc++ 4.7+ which isn't present on precise.
So we now include a newer libstdc++ in the compiler bundle (meaning
this clang should still run on precise).
* clang is broken for android at r202554. To unblock oilpan, merge three
later changes into this roll, llvm r202793, r203601, and r203635
Regular, less tricky clang roll stuff:
* Disable the new warning -Wabsolute-value for now (crbug.com/351479
for turning it on)
* Disable -Wno-tautological-pointer-compare for libxml where it now
fires.
* Since this bundles a new version of the oilpan plugin, bump its suffix to _3
* Change plugin code to track upstream api change
* Remove plugin flag check-url-directory as that's now always on
Due to the c++11 stuff, it's likely that this change will get reverted a few times.
BUG=351479, 287029,341352,333968,335325
TBR=hans@chromium.org
Review URL: https://codereview.chromium.org/195623002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257618 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
process_resources writes all inputs to a filelist, and then passes the md5sum
of the filelist as parameter (so that the commandline changes when inputs are
removed, causing a rerun).
Instead, just make the input filelist another input. gyp writes filelists when
their contents change, so this means if inputs are removed, the mtime of the
filelist will change, also causing a rebuild.
No intended behavior change.
BUG=177552
NOTRY=true
Review URL: https://codereview.chromium.org/199993003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257464 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
builds,
* Slow link times.
* Slow gdb startup times.
Lots more detailed information at http://gcc.gnu.org/wiki/DebugFission
Overall, this improves linking speed of debug Chrome builds on Linux
by ~12% and speeds up gdb by around 30%.
This requires a objcopy with --extract-dwo object (binutils newer then
2.22.52.0.4 // 2.23). Ubuntu Precise only comes with 2.23
BUG=
Review URL: https://codereview.chromium.org/197013010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257424 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This allows to do a PGO optimized build of Chrome with the following commands:
python build\gyp_chromium -Dchrome_pgo_phase=1
ninja -C out\Release chrome
run with '--no-sandbox' + pgosweep
python build\gyp_chromium -Dchrome_pgo_phase=2
ninja -C out\Release chrome
----- Approach that didn't worked -----
(see comment #13 to know why this didn't work)
Instead of having the following gyp dependency chain (for a regular build), here '->' means 'depends on':
'chrome'->|'chrome_main_dll'
----------|'chrome_child_dll'
we know have the following one (when chrome_pgo==1):
'chrome'->|'chrome_main_dll' |->'chrome_pgo_optimize'->|'chrome_main_dll_pgi'
----------|'chrome_child_dll'|-------------------------|'chrome_child_dll_pgi'
The '*_pgi' target correspond to the instrumented dll, the name of the DLLs produced by target will be terminated by '_pgi'.
During the 'chrome_pgo_optimize' step the instrumented DLLs will be renamed (the '_pgi' suffix will be removed) and Chrome will be run against a set of profile test cases, pgosweep.exe will also be invoked to collect the instrumentation data.
Then the main targets ('chrome_main_dll' and 'chrome_child_dll') will be linked with the flag /LTCG:PGOPTIMIZE, this will produce the optimized DLLs.
--------------------------------------------
R=scottmg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/187813008
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257133 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
noamsml@chromium.org
thakis@chromium.org
jbudorick@chromium.org
sky@chromium.org
senorblanco@chromium.org
rmcilroy@chromium.org
jdduke@chromium.org
torne@chromium.org
scottmg@chromium.org
davve@opera.com
petarj@mips.com
newt@chromium.org
zty@chromium.org
aurimas@chromium.org
wittman@chromium.org
sebmarchand@chromium.org
pneubeck@chromium.org
andrewhayden@chromium.org
mithro@mithis.com
derat@chromium.org
bajones@chromium.org
zhenyu.liang@intel.com
rbyers@chromium.org
dpranke@chromium.org
fischman@chromium.org
jochen@chromium.org
binji@chromium.org
mef@chromium.org