gn win: Automatically find location of Visual Studio Previously, a vcvarsall or equivalent command was required to have been run before GN, and the build files did not attempt to locate the Visual Studio installation. Additionally, the tools in the PATH were assumed to be compatible with the setting of target_cpu as given to GN, and the build would confusingly error out otherwise. Now, at GN-time, the location of the VS2015 install is found, the required environment extracted from vcvarsall and saved, and this environment is used when invoking the compiler, linker, and assembler. Unfortunately this requires a bunch of goop in win_helper.py (mostly from old Chromium). Currently, the x64 toolchain is always used. In a follow up change, the toolchain definition should be templated and the correct one chosen based on the value of target_cpu. Bug: crashpad:79 Change-Id: Id6150f3a80b9f26154b30312605989b89e479313 Reviewed-on: https://chromium-review.googlesource.com/905572 Reviewed-by: Mark Mentovai <mark@chromium.org>
This is mini_chromium, a small collection of useful low-level (“base”) routines from the Chromium open-source project. Chromium is large, sprawling, full of dependencies, and a web browser. mini_chromium is small, self-contained, and a library. mini_chromium is especially useful as a dependency of other code that wishes to use Chromium’s base routines. By using mini_chromium, other projects’ code can function in a standalone environment outside of Chromium without having to treat all of Chromium as a dependency. When building as part of Chromium, those projects’ code can use Chromium’s own (non-mini_chromium) base implementation.
Code provided in mini_chromium provides the same interface as the equivalent code in Chromium.
While it’s a goal of mini_chromium to maintain interface compatibility with Chromium’s base library for the interfaces it does implement, there’s no requirement that it use the same implementations as Chromium’s base library. Many of the implementations used in mini_chromium are identical to Chromium’s, but many others have been modified to eliminate dependencies that are not desired in mini_chromium, and a few are completely distinct from Chromium’s altogether. Additionally, when mini_chromium provides an interface in the form of a file or class present in Chromium, it’s not bound to provide all functions, methods, or types that the Chromium equivalent does. The differences noted above notwithstanding, the interfaces exposed by mini_chromium’s base are and must remain a strict subset of Chromium’s.
Crashpad is the chief consumer of mini_chromium.
Mark Mentovai
mark@chromium.org