- Remove the use of the mac specific type 'application' and use 'executable'
with 'mac_bundle' set to 1.
- update common.gypi to default mac_bundle to zero.
- update common.gypi to look at mac_bundle for some of the base behaviors that
were on 'application'.
- Roll DEPS to get the new version of gyp w/ the matching support.
Review URL: http://codereview.chromium.org/50015
git-svn-id: http://src.chromium.org/svn/trunk/src/build@12136 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
(note: this change now requires a P4 to build. It's easy to back it
out for older processors, but they shouldn't be used to run
layout-tests.)
We are seeing issues where the opt build ends up with very slightly
different colours in layout tests than the debug build. This is
probably due to floating point rounding differences.
All floating-point computations on x87 happens in 80-bit precision.
Because the C and C++ language standards allow the compiler to keep
the floating-point values in higher precision than what's specified in
the source and doing so is more efficient than constantly rounding up
to 64-bit or 32-bit precision as specified in the source, the
compiler, especially in the optimized mode, tries very hard to keep
values in x87 floating-point stack (in 80-bit precision) as long as
possible. This has important side effects, that the real value used in
computation may change depending on how the compiler did the
optimization - that is, the value kept in 80-bit is different than the
value rounded down to 64-bit or 32-bit. There are possible compiler
options to make this behavior consistent (e.g. -ffloat-store would
keep all floating-values in the memory, thus force them to be rounded
to its original precision) but they have significant runtime
performance penalty.
-mfpmath=sse -msse2 makes the compiler use SSE instructions which keep
floating-point values in SSE registers in its native precision (32-bit
for single precision, and 64-bit for double precision values). This
means the floating-point value used during computation does not change
depending on how the compiler optimized the code, since the value is
always kept in its specified precision.
Internal performace tests of these options shows that it's not a clear
performance win or loss across the board.
git-svn-id: http://src.chromium.org/svn/trunk/src/build@11751 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
I snagged the wrong rev last time.
Reverting back to 11622, which had the comment:
---------------
r11622 | ager@chromium.org | 2009-03-12 23:53:03 -0700 (Thu, 12 Mar 2009) | 6 lines
Update V8 to version 1.1.1.
Contains a couple of layout tests rebaselines.
This time contains an updated gyp file for the mac build.
Review URL: http://codereview.chromium.org/43134
---------------
This also includes the other file change in 11624:
---------------
r11624 | ager@chromium.org | 2009-03-13 02:17:01 -0700 (Fri, 13 Mar 2009) | 6 li
nes
Update V8 to fix an assertion that does not hold.
Add test that tests arbitrary limits on expressions that can be
handled without stack overflows to the test list. I have filed a bug
report and Kevin is investigating.
Review URL: http://codereview.chromium.org/46029
---------------
trb=darin,ager
Review URL: http://codereview.chromium.org/46048
git-svn-id: http://src.chromium.org/svn/trunk/src/build@11654 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
systems we build and install proper Debian packages instead of directly
installing files into the filesystem.
This allows the user to cleanly uninstall the packages and it prevents
corruption from us accidentally overwriting files that the system
tries to manage itself.
Also, the script now installs debugging symbols where available. This allows
gdb to step into system libraries. The developer still needs to download the
actual source code with "apt-get source" and point the debugger to it.
Review URL: http://codereview.chromium.org/40288
git-svn-id: http://src.chromium.org/svn/trunk/src/build@11336 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
* Catch up to recent changes:
* Rename RenderThemeChromiumGtk.cpp to RenderThemeChromiumLinux.cpp.
* Fix spelling of V*NPObject.{cpp,h}
* Explicitly include varions WebCore *Gtk.cpp and *Linux.cpp files that
are excluded by the general regular expression.
* Add webinput_event_util.cc.
* Exclude glue/plugins/plugin_stubs.cc.
* Add a Linux test_shell_resources target to build
test_shell_resources.{h,pak}.
* Add an explicit test_shell action to repack resources into test_shell.pak.
* Use -Wno-multichar when building libtest_shell_common.a.
* Use -DWTF_USE_PTHREADS when building libwtf.a, and when dependent
targets compile against it.
* Use tools/test_shell/test_shell_main{,_GYP}.scons as the main
entry point for GYP-based builds of webkit.
* Add base/gfx/gtk_util.cc to the base build.
Review URL: http://codereview.chromium.org/39219
git-svn-id: http://src.chromium.org/svn/trunk/src/build@11160 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
* Add a GYP=1 command-line variable to use the gyp-generated files
(which are generated side-by-side until everything's okay enough
to cut over for real).
* Rearrange existing *.scons files to match the layout of the
gyp-generated ones, so the transition will be easier:
* base.scons (the wrapping logic that calls the other *.scons files)
=> base_sln.scons
* base_lib.scons (the library itself)
=> base.scons (matching the gyp target generation)
* gfx/base_gfx.scons
=> base_gfx.scons (with necessary prepending of "gfx/" to path names)
build/SConscript.main fixes:
* Use an internal ${_GYP} infix variable to select the right flavor
of *.scons file (multiple places)
* When building with GYP=1, only load the one component *_sln_gyp.scons
file, because gyp has already created it with knowledge of all the
right dependent *_gyp.scons files to load.
Linux gyp build fixes:
* Add -32 to $ASFLAGS for generating a 32-bit libicudata.a from the
now-checked in .s.
* Add -Wno-unused and -Wno-unused-function to skia.
Review URL: http://codereview.chromium.org/28207
git-svn-id: http://src.chromium.org/svn/trunk/src/build@10759 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
To fix this issue, this change adds a new function TrimWhitespaceUTF8(), which trims space characters (including non-printable characters and broken UTF-8 characters) from either end of a UTF-8 string.
Please feel free to give me your comments since I'm not sure this implimentation is correct. (Maybe this implementation trims too aggressively.)
BUG=7377
Review URL: http://codereview.chromium.org/20219
git-svn-id: http://src.chromium.org/svn/trunk/src/build@10456 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
- fix scons dependencies by adding a target for grit/theme_resources.h
- fix mac build by adding grit to unittest include path
- fix check deps by adding rules for /grit dir.
Create a chrome_resources.vcproj that holds grd files that hold
non-string resources. Put browser_resources.grd into this vcproj.
Port theme_resources.rc/theme_resources.h to theme_resources.grd
and put it in the vcproj too.
I did a find/replace on the theme_resources include line.
Modify grit so header files go in grit_generated_resources/grit/
so the include path can be cleaner. I'll migrate the others
in follow up patches.
theme_resources.rc had a conditional include of distribution_resources.rc
so I had to add support for preprocessor defines to visual studio.
Review URL: http://codereview.chromium.org/24011
git-svn-id: http://src.chromium.org/svn/trunk/src/build@9664 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
thomasvl@chromium.org
hclam@chromium.org
ager@chromium.org
maruel@chromium.org
bradnelson@google.com
agl@chromium.org
sgk@google.com
jar@chromium.org
mark@chromium.org
deanm@chromium.org
markus@chromium.org
jrg@chromium.org
hbono@chromium.org
evan@chromium.org
mmoss@chromium.org
tc@google.com
iposva@chromium.org