The ninja generator of gyp behaves strangely on the 'libraries' field of link
settings, for example, specifying path to an external library works well on
both xcodebuild and msvc generators, but the ninja generator would link to
the wrong path (it can neither translate relative path correctly, nor convert
the command line parameter to the '-lxxx' form).
The only way to make all generators work on all platforms is to use abusolute
paths for external libraries.
* vendor/libchromiumcontent fc02d93...f4f8a7e (4):
> Include encryptor.lib and its symbols and headers in the distribution
> Build encryptor.lib on Windows
> Revert all changes before building if any unexpected files are modified
> Export headers from cc/
DevToolsWindow represents a vanilla top-level window that shows the dev tools.
It uses ui::WindowImpl to implement window functionality, which requires a
newer libchromiumcontent which contains the necessary headers for using that
class, and requires some modifications to brightray.gypi to make WTL's headers
available.
* vendor/libchromiumcontent 2f53a96...fc02d93 (4):
> Export third_party/wtl/include headers
> Export test_support_base.pdb and test_support_content.pdb
> Fix linker errors with test_support_base on Windows
> Fix linker errors with base_prefs_test_support on Windows
We were querying the application's FILEVERSIONINFO every time we needed to
figure out the path for storing BrowserContext data. Now we cache the path the
first time we need it, which is during application initialization and before IO
prohibitions begin.
I.e., use CFBundleShortVersionString instead of CFBundleVersion on OS X and
ProductVersion instead of FileVersion on Windows.
This is generally more useful (although slightly lower granularity) than the
machine-readable version number.
We need to put them inside the target_defaults dictionary. Now that these
settings are turned on, we need to ignore some warnings that Chromium ignores.
This class doesn't implement any devtools behavior yet. Right now it's just a
glorified wrapper around a content::WebContents. But it's enough to show web
content on screen on Windows!
* vendor/libchromiumcontent 04ccdd8...31efc77 (3):
> Use the DLL version of the CRT
> Generate libchromiumcontent-symbols.zip on Windows
> Fix exporting of WebKit symbols
This is required to get base::win::PEImage, which is required by sandboxing
code.
* vendor/libchromiumcontent c973a7c...04ccdd8 (1):
> Export base_static.lib for Windows clients
* vendor/libchromiumcontent 15ada44...c973a7c (3):
> Create and export sandbox_static.lib for Windows clients
> Export content/app/startup_helper_win.cc to clients
> Rename dist/include to dist/src
