Remove references to gyp from DEPS and docs
Bug: 826218
Change-Id: I176e1aeb0b24b21c6b4e5ee40910dce2bce52c95
Reviewed-on: https://chromium-review.googlesource.com/1239461
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Daniel Bratell <bratell@opera.com>
Cr-Commit-Position: refs/heads/master@{#593522}diff --git a/docs/android_test_instructions.md b/docs/android_test_instructions.md
index 6fc4649..25c447add 100644
--- a/docs/android_test_instructions.md
+++ b/docs/android_test_instructions.md
@@ -158,9 +158,7 @@
When adding a new JUnit test, the associated `BUILD.gn` file must be updated.
For example, adding a test to `chrome_junit_tests` requires to update
-`chrome/android/BUILD.gn`. If you are a GYP user, you will not need to do that
-step in order to run the test locally but it is still required for GN users to
-run the test.
+`chrome/android/BUILD.gn`.
```shell
# Build the test suite.
diff --git a/docs/angle_in_chromium.md b/docs/angle_in_chromium.md
index eacc6f4..282a2cf 100644
--- a/docs/angle_in_chromium.md
+++ b/docs/angle_in_chromium.md
@@ -23,8 +23,7 @@
> gclient runhooks
```
-To check ANGLE builds (assumes you ran hooks with GYP\_GENERATORS=ninja) without
-building all of Chromium.
+To check ANGLE builds without building all of Chromium.
```shell
ninja -C out\Release libEGL.dll
diff --git a/docs/ccache_mac.md b/docs/ccache_mac.md
index 7eed51a6..4b3eacd 100644
--- a/docs/ccache_mac.md
+++ b/docs/ccache_mac.md
@@ -36,8 +36,8 @@
Make sure ccache can be found in your `$PATH`.
You can also just use the current released version of ccache (3.1.8 or 3.1.9)
-and disable the chromium style plugin with `clang_use_chrome_plugins=0` in your
-`GYP_DEFINES`.
+and disable the chromium style plugin with `clang_use_chrome_plugins = false`
+in your args.gn.
## Use with GN
diff --git a/docs/eclipse.md b/docs/eclipse.md
index af35097..d71522c 100644
--- a/docs/eclipse.md
+++ b/docs/eclipse.md
@@ -59,13 +59,6 @@
* Disable build before launching
* Select Run/Debug > Launching
* Uncheck Build (if required) before launching
- * File types for .gyp and .gypi
- * Go to General > Editors > File Associations
- * Add `*.gyp` and `*.gypi` file types, and associate them with Python Editor
- * See http://pydev.org/index.html for instructions on getting a Python
- Editor configured in Eclipse
- * Enjoy a happy life with Ctrl+Shift+P and automatic matching bracket
- highlight.
* Tab ordering
* If you prefer ordering your tabs by most recently used, go to General >
Appearance and check Show most recently used tabs
@@ -122,17 +115,6 @@
* Uncheck Index source files not included in the build
* Uncheck Allow heuristic resolution of includes
* Click Apply to commit the changes
- * C/C++ Paths and Symbols. This help Eclipse build the symbol table for Chrome.
- * From a shell, run `GYP_GENERATORS=eclipse build/gyp_chromium`
- * This generates `<project root>/out/Release/eclipse-cdt-settings.xml` which
- is used below.
- * Select C/C++ General > Paths and Symbols from the tree on the left
- * Click Restore Defaults to clear any old settings
- * Click Import Settings... The import dialog should appear.
- * Click Browse... A file browser should appear.
- * Select `<project root>/out/Release/eclipse-cdt-settings.xml`.
- * Click the Finish button. The entire preferences dialog should go away.
- * Right click on the project and select Index > Rebuild
* Java
* Create a link from `<project root>/.classpath` to
`<project root>/tools/android/eclipse/.classpath`:
diff --git a/docs/emacs.md b/docs/emacs.md
index 434d3252..a35bafa 100644
--- a/docs/emacs.md
+++ b/docs/emacs.md
@@ -187,21 +187,7 @@
Note: You might need to grab the latest version of
[whitespace.el](http://www.emacswiki.org/emacs-en/download/whitespace.el).
-## gyp
-
-### `gyp` style
-There is a gyp mode that provides basic indentation and font-lock (syntax
-highlighting) support. The mode derives from python.el (bundled with newer
-emacsen).
-
-You can find it in /src/tools/gyp/tools/emacs
-
-See the README file there for installation instructions.
-
-**Important**: the mode is only tested with `python.el` (bundled with newer
-emacsen), not with `python-mode.el` (outdated and less maintained these days).
-
-### deep nesting
+## deep nesting
A couple of helpers that show a summary of where you are; the first by tracing
the indentation hierarchy upwards, the second by only showing `#if`s and
diff --git a/docs/gpu/debugging_gpu_related_code.md b/docs/gpu/debugging_gpu_related_code.md
index 765942c..0c350e6 100644
--- a/docs/gpu/debugging_gpu_related_code.md
+++ b/docs/gpu/debugging_gpu_related_code.md
@@ -88,7 +88,7 @@
You can often make a simple OpenGL-ES-2.0-only C++ reduced test case that is
relatively quick to compile and test, by adding tests to the `gl_tests` target.
Those tests exist in `src/gpu/command_buffer/tests` and are made part of the
-build in `src/gpu/gpu.gyp`. Build with `ninja -C out/Debug gl_tests`. All the
+build in `src/gpu/BUILD.gn`. Build with `ninja -C out/Debug gl_tests`. All the
same command line options listed on this page will work with the `gl_tests`,
plus `--gtest_filter=NameOfTest` to run a specific test. Note the `gl_tests`
are not multi-process, so they probably won't help with race conditions, but
diff --git a/docs/gpu/gpu_testing.md b/docs/gpu/gpu_testing.md
index 2dcc5a7b1..3becd8b3 100644
--- a/docs/gpu/gpu_testing.md
+++ b/docs/gpu/gpu_testing.md
@@ -422,7 +422,7 @@
If you are adding a new test to one of the existing tests (e.g., `pixel_test`),
all you need to do is make sure that your new test runs correctly via isolates.
See the documentation from the GPU bot details on [adding new isolated
-tests][new-isolates] for the `GYP_DEFINES` and authentication needed to upload
+tests][new-isolates] for the gn args and authentication needed to upload
isolates to the isolate server. Most likely the new test will be Telemetry
based, and included in the `telemetry_gpu_test_run` isolate. You can then
invoke it via:
diff --git a/docs/gpu/pixel_wrangling.md b/docs/gpu/pixel_wrangling.md
index f900b103..42b73463 100644
--- a/docs/gpu/pixel_wrangling.md
+++ b/docs/gpu/pixel_wrangling.md
@@ -83,11 +83,11 @@
`pixel_integration_test.py`
* Stress tests of the screenshot functionality other tests use:
`screenshot_sync_integration_test.py`
-* `angle_unittests`: see `src/gpu/gpu.gyp`
+* `angle_unittests`: see `src/third_party/angle/src/tests/BUILD.gn`
* drawElements tests (on the chromium.gpu.fyi waterfall): see
`src/third_party/angle/src/tests/BUILD.gn`
* `gles2_conform_test` (requires internal sources): see
- `src/gpu/gles2_conform_support/gles2_conform_test.gyp`
+ `src/gpu/gles2_conform_support/BUILD.gn`
* `gl_tests`: see `src/gpu/BUILD.gn`
* `gl_unittests`: see `src/ui/gl/BUILD.gn`
diff --git a/docs/ipc_fuzzer.md b/docs/ipc_fuzzer.md
index 7cf3c96..79331c94 100644
--- a/docs/ipc_fuzzer.md
+++ b/docs/ipc_fuzzer.md
@@ -13,8 +13,7 @@
### Build instructions
-* Run `gn args` and add `enable_ipc_fuzzer = true` to your args.gn. If you use
- GYP, add `enable_ipc_fuzzer=1` to `GYP_DEFINES`.
+* Run `gn args` and add `enable_ipc_fuzzer = true` to your args.gn.
* build `ipc_fuzzer_all` target
* component builds are currently broken, sorry
* Debug builds are broken; only Release mode works.
@@ -43,7 +42,7 @@
### ipcdump logger
-* add `enable_ipc_fuzzer=1` to `GYP_DEFINES`
+* add `enable_ipc_fuzzer = true` to `args.gn`
* build `chrome` and `ipc_message_dump` targets
* run chrome with
`--no-sandbox --ipc-dump-directory=/path/to/ipcdump/directory`
diff --git a/docs/linux_chromium_arm.md b/docs/linux_chromium_arm.md
index 180a497..0013f68 100644
--- a/docs/linux_chromium_arm.md
+++ b/docs/linux_chromium_arm.md
@@ -23,8 +23,8 @@
### Installing the sysroot
A prebuilt sysroot image is kept up to date on Cloud Storage. It will
-automatically be installed by gclient runhooks installed if you have
-`target_arch=arm` in your `GYP_DEFINES`.
+automatically be installed by gclient runhooks if `target_cpu=["arm"]`
+is present in your `.gclient` file.
To install the sysroot manually you can run:
diff --git a/docs/linux_debugging.md b/docs/linux_debugging.md
index c69b0fa..fb8947f 100644
--- a/docs/linux_debugging.md
+++ b/docs/linux_debugging.md
@@ -458,9 +458,7 @@
## Breakpad
-See the last section of [Linux Crash Dumping](linux_crash_dumping.md); you
-need to set a gyp variable and an environment variable for the crash dump tests
-to work.
+See the last section of [Linux Crash Dumping](linux_crash_dumping.md).
## Drag and Drop
diff --git a/docs/linux_hw_video_decode.md b/docs/linux_hw_video_decode.md
index 44d2b8f7..a64f14a2 100644
--- a/docs/linux_hw_video_decode.md
+++ b/docs/linux_hw_video_decode.md
@@ -47,11 +47,11 @@
make -j32 && rm -f ${DEST}/lib/dri/{nvidia_drv_video.so,s3g_drv_video.so} && make install
```
-* Add to `$GYP_DEFINES`:
- * `chromeos=1` to link in `VaapiVideoDecodeAccelerator`
- * `proprietary_codecs=1 ffmpeg_branding=Chrome` to allow Chrome to play
- h.264 content, which is the only codec VAVDA knows about today.
-* Re-run gyp (`./build/gyp_chromium` or `gclient runhooks`)
+* Add to args.gn:
+ * `target_os = "chromeos"` to link in `VaapiVideoDecodeAccelerator`
+ * `proprietary_codecs = true` and `ffmpeg_branding = "Chrome"` to
+ allow Chrome to play h.264 content, which is the only codec
+ VAVDA knows about today.
* Rebuild chrome
* Run chrome with `LD_LIBRARY_PATH=${HOME}/apps/libva/lib` in the environment,
and with the `--no-sandbox` command line flag.
diff --git a/docs/linux_profiling.md b/docs/linux_profiling.md
index 694e4e9..4265909 100644
--- a/docs/linux_profiling.md
+++ b/docs/linux_profiling.md
@@ -55,16 +55,11 @@
### google-perftools
-google-perftools code is enabled when the `use_allocator` variable in gyp is set
+google-perftools code is enabled when the `use_allocator` gn variable is set
to `tcmalloc` (currently the default). That will build the tcmalloc library,
including the cpu profiling and heap profiling code into Chromium. In order to
get stacktraces in release builds on 64 bit, you will need to build with some
-extra flags enabled by setting `profiling=1` in gyp.
-
-If the stack traces in your profiles are incomplete, this may be due to missing
-frame pointers in some of the libraries. A workaround is to use the
-`linux_keep_shadow_stacks=1` gyp option. This will keep a shadow stack using the
-`-finstrument-functions` option of gcc and consult the stack when unwinding.
+extra flags enabled by setting `enable_profiling = true` in args.gn
In order to enable cpu profiling, run Chromium with the environment variable
`CPUPROFILE` set to a filename. For example:
diff --git a/docs/linux_suid_sandbox_development.md b/docs/linux_suid_sandbox_development.md
index 03aceca..9ce6808 100644
--- a/docs/linux_suid_sandbox_development.md
+++ b/docs/linux_suid_sandbox_development.md
@@ -83,4 +83,4 @@
The `CHROME_DEVEL_SANDBOX` variable is intended for developers and won't work
for a system-wide installation of Chromium. Package maintainers should make sure
-the `setuid` binary is installed and defined in GYP as `linux_sandbox_path`.
+the `setuid` binary is installed.
diff --git a/docs/memory-infra/README.md b/docs/memory-infra/README.md
index 37404df..f73d843 100644
--- a/docs/memory-infra/README.md
+++ b/docs/memory-infra/README.md
@@ -140,9 +140,8 @@
event? Which subsystem increased? Did memory not go down as expected after
closing a tab? Which other threads were active during a bloat?
* **Works out of the box on desktop and mobile.**
- No recompilations with unmaintained `GYP_DEFINES`, no time-consuming
- symbolizations stages. All the logic is already into Chrome, ready to dump at
- any time.
+ No recompilations, no time-consuming symbolizations stages. All the
+ logic is already in Chrome, ready to dump at any time.
* **The same technology is used for telemetry and the ChromePerf dashboard.**
See [the slides][chromeperf-slides] and take a look at
[some ChromePerf dashboards][chromeperf] and
diff --git a/docs/using_a_linux_chroot.md b/docs/using_a_linux_chroot.md
index da37cfe..a8f4304 100644
--- a/docs/using_a_linux_chroot.md
+++ b/docs/using_a_linux_chroot.md
@@ -16,7 +16,7 @@
Run `build /install-build-deps.sh`, then exit the rooted chroot.
* Delete your out/ directory if you had a previous non-chrooted build.
* To enter your chroot as normal user, run `schroot -c lucid64`.
-* Now run `build/gyp_chromium`, compile and run DumpRenderTree within chroot.
+* Now compile and run DumpRenderTree within chroot.
## Tips and Tricks
diff --git a/docs/vanilla_msysgit_workflow.md b/docs/vanilla_msysgit_workflow.md
index b834874a..2c04cb00 100644
--- a/docs/vanilla_msysgit_workflow.md
+++ b/docs/vanilla_msysgit_workflow.md
@@ -73,10 +73,10 @@
you use my naming convention or not), you can know before hand when you
switch between branches on Windows whether you should expect a major
rebuild, or a minor rebuild. If you are able to remember which of your
- topic branches have .gyp changes and which don't (or I guess you could use
+ topic branches have gn changes and which don't (or I guess you could use
`git diff` to figure this out), then you will also have a good idea whether
you need to run `gclient runhooks` or not when you switch branches. Another
- nice thing is that yu should never have to run `gclient sync` when you
+ nice thing is that you should never have to run `gclient sync` when you
switch between branches with the same base revision, unless some of your
branches have changes to DEPS files.
diff --git a/docs/windows_split_dll.md b/docs/windows_split_dll.md
index e7f4c2cf..e8aac58 100644
--- a/docs/windows_split_dll.md
+++ b/docs/windows_split_dll.md
@@ -5,37 +5,10 @@
## How
-Normally, you probably don't need to worry about doing this build. If for some
-reason you need to build it locally:
+Split DLL is now default on Windows and controlled by the
+`is_multi_dll_chrome` gn variable.
-1. From a _Visual Studio Command Prompt_ running as **Administrator** run
- `python tools\win\split_link\install_split_link.py`.
-1. Set `GYP_DEFINES=chrome_split_dll=1`. In particular, don't have
- `component=shared_library`. Other things, like `buildtype` or `fastbuild`
- are fine.
-1. `gclient runhooks`
-1. `ninja -C out\Release chrome`
-
-`chrome_split_dll` currently applies only to chrome.dll (and not test binaries).
-
-## What
-
-This is intended to be a temporary measure until either the toolchain is
-improved or the code can be physically separated into two DLLs (based on a
-browser/child split).
-
-The link replacement forcibly splits chrome.dll into two halves based on a
-description in `build\split_link_partition.py`. Code is primarily split along
-browser/renderer lines. Roughly, Blink and its direct dependencies are in the
-"chrome1.dll", and the rest of the browser code remains in "chrome.dll".
-
-TODO: build\split_link_partition.py doesn't exist.
-
-Splitting the code this way allows keeping maximum optimization on the Blink
-portion of the code, which is important for performance.
-
-There is a compile time define set when building in this mode
-`CHROME_SPLIT_DLL`, however it should be used very sparingly-to-not-at-all.
+`is_multi_dll_chrome` applies only to chrome.dll (and not test binaries).
## Details
@@ -44,15 +17,6 @@
forcibly exported from the other DLL. This works relatively cleanly for function
import/export, however it cannot work for data export.
-There are relatively few instances where data exports are required across the
-DLL boundary. The waterfall builder
-https://build.chromium.org/p/chromium/waterfall?show=Win%20Split will detect when
-new data exports are added, and these will need to be repaired. For constants,
-the data can be duplicated to both DLLs, but for writeable data, a wrapping
-set/get function will need to be added.
-
-https://build.chromium.org/p/chromium/waterfall?show=Win%20Split does not exist.
-
Some more details can be found on the initial commit of the split_link script
https://src.chromium.org/viewvc/chrome?revision=200049&view=revision and the
associated bugs: https://crbug.com/237249 https://crbug.com/237267.
diff --git a/tools/DEPS b/tools/DEPS
index 88fa2ec..4a8eca10 100644
--- a/tools/DEPS
+++ b/tools/DEPS
@@ -1,7 +1,6 @@
# checkdeps.py shouldn't check include paths for files in these dirs:
skip_child_includes = [
"clang",
- "gyp",
"traceline",
"perf/page_sets",
]
