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 <[email protected]>
Commit-Queue: Daniel Bratell <[email protected]>
Cr-Commit-Position: refs/heads/master@{#593522}

Author: bratell-at-opera

docs/android_test_instructions.md

@@ -158,9 +158,7 @@ for example, `content_junit_tests` and `chrome_junit_tests`.
 
 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.

docs/angle_in_chromium.md

@@ -23,8 +23,7 @@ Clone the ANGLE git repository.
 > 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

docs/ccache_mac.md

@@ -36,8 +36,8 @@ git clone git://git.samba.org/ccache.git cd ccache
 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
 

docs/eclipse.md

@@ -59,13 +59,6 @@ settings below are inside Window > Preferences.
  * 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 @@ settings below are inside Window > Preferences.
     * 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`:

docs/emacs.md

@@ -187,21 +187,7 @@ One nice way to highlight long lines and other style issues:
 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

docs/gpu/debugging_gpu_related_code.md

@@ -88,7 +88,7 @@ glPopGroupMarkerEXT();                 // -> log prefix = "Foo.That"
 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

docs/gpu/gpu_testing.md

@@ -422,7 +422,7 @@ single step.
 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:

docs/gpu/pixel_wrangling.md

@@ -83,11 +83,11 @@ test the code that is actually shipped. As of this writing, the tests included:
         `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`
 

docs/ipc_fuzzer.md

@@ -13,8 +13,7 @@ contribute.
 
 ### 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 @@ contribute.
 
 ### 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`

docs/linux_chromium_arm.md

@@ -23,8 +23,8 @@ and library dependencies directly from Ubuntu:
 ### 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:
 

docs/linux_debugging.md

@@ -458,9 +458,7 @@ with the appropriate instructions if you know what they are.)
 
 ## 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
 

docs/linux_hw_video_decode.md

@@ -47,11 +47,11 @@ on a gprecise setup.
     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.

docs/linux_profiling.md

@@ -55,16 +55,11 @@ This will use the previously captured data (`perf.data`).
 
 ### 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:

docs/linux_suid_sandbox_development.md

@@ -83,4 +83,4 @@ You can also make such an installation more permanent by following the
 
 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.

docs/memory-infra/README.md

@@ -140,9 +140,8 @@ contextual data:
    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

docs/using_a_linux_chroot.md

@@ -16,7 +16,7 @@ chroot.
     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
 

docs/vanilla_msysgit_workflow.md

@@ -73,10 +73,10 @@ switching between branches):
     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.
 

docs/windows_split_dll.md

@@ -5,37 +5,10 @@ undertaken as one possible workaround for toolchain limitations on Windows.
 
 ## 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 @@ the other, and causing unresolved externals that result during linking to be
 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.

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",
 ]