These vsprops used to be used to setup the branding #defines.
This is now handled in common.gypi.
This is an incremental step toward dropping vsprops entirely for release.
BUG=None
TEST=None
TBR=maruel
Review URL: http://codereview.chromium.org/523020
git-svn-id: http://src.chromium.org/svn/trunk/src/build@35367 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Added API for managing buffers to Pepper 3D device.
Removed DCHECK from WebPluginImpl::SetWindow that checks against a windowless plugin being given a window handle. Please check this! Now an initially windowless plugin instance gets a handle when it requests a Pepper 3D context. Perhaps the window handle should be concealed from the underlying plugin isntance.
Removed enable_gpu gyp variable and C macro. GPU code is always built on windows but not mac or linux. It is enabled at runtime with the --enable-gpu-plugin switch.
Redesigned CommandBuffer interface so it exposes shared memory through a Buffer. This was necessary because Pepper has no notion of shared memory handles. The Buffer exposes the shared memory as both a handle (through base::SharedMemory) and the mapped address and size.
Refactored CommandBufferEngine so mapped shared memory addresses and sizes are returned with a single call rather than two separate calls.
Added 3D demo to pepper test plugin.
TEST=try servers
BUG=none
Review URL: http://codereview.chromium.org/367002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@35185 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This CL is required for supporting Native Client on 64bit Windows. On Win64 we will use a 64bit executable to load NaCl modules. Since we have only one version of Chrome on Windows, this executable has to be built together with 32bit Chrome binaries.
For the targets that are required for both 32bit and 64bit builds, this CL moves the shared parts of the target definitions into targetspecific gypi files (such as base.gypi). New 64bit only targets are added. Since we would like to port as few code as possible at this point, some 64bit targets include less source files or less dependencies than the original 32bit targets. These targets will have nacl_win64 in their name to emphasize that they should be used for NaCl only. Some 64bit targets are identical to the 32bit targets in everything except for the target platform these will have only win64 in their name.
TEST=none
BUG=28176
Review URL: http://codereview.chromium.org/384068TBR=gregoryd@google.com
Review URL: http://codereview.chromium.org/501125
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34990 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This CL is required for supporting Native Client on 64-bit Windows. On Win64 we will use a 64-bit executable to load NaCl modules. Since we have only one version of Chrome on Windows, this executable has to be built together with 32-bit Chrome binaries.
For the targets that are required for both 32-bit and 64-bit builds, this CL moves the shared parts of the target definitions into target-specific gypi files (such as base.gypi). New 64-bit only targets are added. Since we would like to port as few code as possible at this point, some 64-bit targets include less source files or less dependencies than the original 32-bit targets. These targets will have nacl_win64 in their name - to emphasize that they should be used for NaCl only. Some 64-bit targets are identical to the 32-bit targets in everything except for the target platform - these will have only win64 in their name.
TEST=none
BUG=28176
Review URL: http://codereview.chromium.org/384068
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34983 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In the previous CL I made the build of pepper_test_plugin conditional
but forgot to remove the unconditional reference, leaving the build breakage
on Linux.
TBR=jrg,asargent,skylined
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/485008
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34232 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
There were problems building Skia and others for the 64-bit linux versions of the
Pepper test plugin, so I have disabled building that plugin except on Windows for now
and added a TODO.
One significant addition to the previous comment lines. The flag enable_gpu=1 now
causes the build definition ENABLE_GPU=1 to allow guarding of dependent code.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/481001
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34227 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is needed because the NaCl plugin code that runs in the renderer
needs to use Pepper APIs all the time, and NaCl support has been enabled
by default for several months now. To cause an untrusted Pepper plugin
to run in the renderer one needs to specify the internalpepper flag.
I have also removed the enable_pepper flag from gyp. As the build of the
GPU process was tied to this flag, I have renamed the flag to enable_gpu.
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/464074TBR=sehr@google.com
Review URL: http://codereview.chromium.org/475004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34162 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is needed because the NaCl plugin code that runs in the renderer
needs to use Pepper APIs all the time, and NaCl support has been enabled
by default for several months now. To cause an untrusted Pepper plugin
to run in the renderer one needs to specify the --internal-pepper flag.
I have also removed the enable_pepper flag from gyp. As the build of the
GPU process was tied to this flag, I have renamed the flag to enable_gpu.
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/464074
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34161 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Previously we built our own copies of many common system libraries.
This comes from our Windows history, where these libraries have to be
carried by any application using them because they aren't provided as
standard.
On Linux, however, they are ubiqutous so we can save binary size by
dynamically linking against the system versions.
TEST=none
BUG=29738
http://codereview.chromium.org/465126
git-svn-id: http://src.chromium.org/svn/trunk/src/build@34084 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
(i.e. this is a plain vanilla build used when layers like base/allocator
are getting in the way of debugging)
and make sure they use msvcrt rather than libcmt
(libcmt is used to help shim malloc/free, but it gets
in the way of valgrind doing the same thing).
Sadly, this is now a gyp-time operation rather than a Configuration
option.
Had to remove hardcoded C prototype for _set_new_mode,
as that caused link errors.
Also add variables win_{release,debug}_{Optimization,RuntimeLibrary}
to let the valgrind build override those settings.
Fix calling convention on _set_new_mode to match the
one in <new.h>
BUG=none
TEST=build with ~/.gyp/include.gypi set as described in comment in common.gypi, gclient runhooks, do release build, verify all exe's and dll's linked against msvcrt dll
Review URL: http://codereview.chromium.org/455037
git-svn-id: http://src.chromium.org/svn/trunk/src/build@33719 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This makes backtraces again include symbols in Debug builds.
TEST=StackTrace.OutputToStream (in a Debug build; the test is
already disabled in Release builds, exactly because this flag
breaks the thing the test is testing.)
Review URL: http://codereview.chromium.org/457006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@33320 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The concept of "ticket promotion" is added to the application when Keystone is
in use. Ticket promotion is used to turn a user Keystone ticket, which Chrome
normally establishes when it launches, into a system Keystone ticket, after
successful user authentication and authorization. Having a system Keystone
with a system ticket means that updates are applied with root privileges
instead of user privileges, essentially eliminating the possibility that a
user will fall off of the auto-update train because they can read and execute
but not write the application.
Two principles of promotion apply:
- An application on a user ticket NEEDS promotion if it determines that it
doesn't have permission to write to itself. Being on a user ticket, an
update attempt would fail.
- An application on a user ticket WANTS promotion if it already NEEDS
promotion. Additionally, if it is installed in a system-wide location
such as /Applications, it will WANT promotion, even if it does not NEED it.
If promotion is needed, an info bar will show up on launch requesting it.
This info bar works similarly to the default browser info bar: it has a "don't
bother me again" button, it will only show up after the first launch, it won't
disappear on navigation if the navigation happens very quickly, and it won't
show itself if another info bar is up. This means that if both the default
browser info bar and the promotion info bar have a shot at showing, only one
will win. In my experience, each wins about half of the time.
If promotion is needed, the update UI in the About window will be hidden.
Checking for updates and offering to apply them doesn't make much sense when
the update won't be able to install successfully. All of the auto-update
machinery is still working in the background, but the About window UI is
hidden.
If promotion is wanted, the About window will contain a new button allowing
the user to enter promotion. This gives access to the same promotion routine
as the promotion info bar. It can be used even from an administrative account
that is able to update the application without promotion. It's intended to be
used by the system administrator of the family without requiring them to
switch to one of the kids' accounts.
BUG=16360
TEST=Exhaustively, please.
Review URL: http://codereview.chromium.org/437053
git-svn-id: http://src.chromium.org/svn/trunk/src/build@33241 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
evan@chromium.org
bradnelson@google.com
jrg@chromium.org
piman@chromium.org
agl@chromium.org
glider@chromium.org
willchan@chromium.org
oshima@chromium.org
apatrick@google.com
gregoryd@google.com
slightlyoff@chromium.org
benl@chromium.org
cmasone@google.com
senorblanco@chromium.org
mmoss@google.com
sehr@google.com
ojan@chromium.org
joel@chromium.org
dank@chromium.org
mark@chromium.org