- Don't pass -s, this doesn't really help anything. The way we will have
to generate our final executables is with -g, and then strip them, since
we will need to keep the original for its symbols.
- Only gc sections in official build. This might slightly improve release
link time (at the cost of size). This allows release to build with GOLD.
Review URL: http://codereview.chromium.org/18846
git-svn-id: http://src.chromium.org/svn/trunk/src/build@8717 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In the presence of an installed copy of the 6.1 SDK, SCons would pick up on the presence of the VC9 toolchain which tags along with it. It would proceed to populate the environment with a mismatched set of paths referring to VC9 includes and libs,
which in turn would cause the chrome base build to terminate with a LNK1103 error complaining of corrupt symbols.
Patch contributed by Siggi @ Google.
git-svn-id: http://src.chromium.org/svn/trunk/src/build@8713 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In the presence of an installed copy of the 6.1 SDK, SCons would pick up on the presence of the VC9 toolchain which tags along with it. It would proceed to populate the environment with a mismatched set of paths referring to VC9 includes and libs,
which in turn would cause the chrome base build to terminate with a LNK1103 error complaining of corrupt symbols.
Patch contributed by Siggi @ Google.
git-svn-id: http://src.chromium.org/svn/trunk/src/build@8665 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
- Strip all symbols. We previously had many exported symbols.
- GC sections. -fdata/function-sections make sure each piece of code/data has it's own section, since GC works on an entire section. I will follow up on the V8 build with the same.
- Remove the ident pragmas. For example, we previously had a string like:
GCC: (GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu1)
Repeated in the .comment section (one for each object?). This data is just metadata.
Review URL: http://codereview.chromium.org/18586
git-svn-id: http://src.chromium.org/svn/trunk/src/build@8636 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Doing a full build seems always fine. The issue is for incremental builds, it corrupts the PDBs. Errors look like:
glue.lib(autofill_form.obj) : fatal error LNK1318: Unexpected PDB error; RPC (23) '(0x000006BA)'
...\xmemory(155) : error C2471: cannot update program database '...\debug\obj\plugin_tests\vc80.pdb'
We'll probably need to upgrade to VS2008 to add it back.
Review URL: http://codereview.chromium.org/17208
git-svn-id: http://src.chromium.org/svn/trunk/src/build@7603 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
base\build\base.vcproj
base\build\base_gfx.vcproj
base\build\base_unittests.vcproj
base\build\debug_message.vcproj
skia\skia.vcproj
testing\gtest.vcproj
third_party\icu38\icu.vcproj
third_party\icu38\icudt.vcproj
third_party\libpng\libpng.vcproj
third_party\zlib\zlib.vcproj
Supporting work in *.scons files:
* Adds .h files to the input_files lists in the various *.scons files.
* Add arguments to ChromeMSVSProject() to actually generate the
.vcproj files.
* Add MSVS.AddConfig() calls to the *.scons files to preserve the
.vsprops inclusion in the generated .vcproj files.
(These will go away eventually as we migrate away from .vsprops
in favor of using the settings from the SCons configuration.)
* Add MSVS.AddConfig() calls to preserve the .vsprops inclusion.
* Move the special generation of dmg_fp/*.cc files ahead of the
input file list so we can list the generated object files.
* Change the 'solutions' Alias to 'msvs' so we don't mislead about
what will actually be generated.
Updates to the new _Node_MSVS.py module with latest from upstream
prototype development:
* Support configurability of:
* buildtarget (used to generat project name)
* RootNamespace
* relative_path_prefix (to prepend './')
* tools (to avoid repetition in the project configs)
* Track the Visual Studio hierarchy in SCons Nodes, not DOM,
so we can delay evaluation until after the complete
configuration has been specified.
* Add a FileList base class for the things that need, with a
subclass hierarchy for the different concrete things in our tree,
and a FileListWalk() function for traversing hierarchies.
* Centralize turning strings into Nodes in the args2nodes() method
and have AddFiles() just use it.
Updates to chromium_builders.py to support all this
* Add knowledge about stripping out noncompilable files
(.h files) from input_files lists.
* Return a Null() class if we're not generating MSVS files
so we don't have to hide the other calls in if:-blocks.
* Add custom ChromeFileList subclass of MSVS.FileList as a
container for the file list manipulation we need to do.
* Move the Chrome*() function definitions out to global space,
and just use the generate() function for adding them to
the passed-in environment as class methods.
* Make a change to SCons (in Node/FS.py) to handle polymorphism in
the new MSVS Node hierarchy.
Review URL: http://codereview.chromium.org/16447
git-svn-id: http://src.chromium.org/svn/trunk/src/build@7467 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
(project files still to come). To wit:
* Solution file configuration is in *_sln.scons files (base\base_sln.scons,
chrome\chrome_sln.scons).
* Individual Project file configuration is in the the .scons file for
the relevant target (base\base_unittests.scons,
third_party\libxml\libxml.scons, etc.)--that is, where their file
lists will live.
* MSVSProject() calls are currently placeholders that establish
the existence of Project Nodes (and Project dependencies) but don't yet
have actual Project configuration information (file lists, .vsprops, etc.).
* Configuraiton is very manual. In particular, the entries in the .sln
file will be written out in exactly the order specified in the
configuration(s). The current ordering is taken from our existing
.sln files, so we can generate virtually the same configurations
on output.
* Generated solution files are nearly byte-for-byte identical
with our existing .sln files, modulo:
* net\dump_cache has a WebsiteProperties sections (making that
configurable per project isn't important right now);
* sandbox\sandbox.sln was missing a dependency of base.vcproj on
on debug_message.vcproj (present in other .sln files)
* webkit\webkit.sln was missing dependencies of WebCore.vcproj on
libxml_config.vcproj and libxslt_config.vcproj (present in
chrome.sln);
* add a handful of other miscellaneous missing dependencies on various
.vcproj definitions in chrome.sln (present in other .sln files).
* remove stats_viewer.csproj from chrome.sln (sorry, mbelshe),
which was complicating the solution configuration with unnecessary
(for us) "Mixed Platform" types;
* All MSVSFolder(), MSVSProject() and MSVSSolution() calls have
hard-wired guid= values taken from our existing configuration,
so we can: 1) verify generation of working configs; 2) minimize
diffs when checking in generated .sln files. We can remove
these in the future in favor of extracting them from existing
.sln files if we wish.
* Add ChromeMSVSFolder(), ChromeMSVSProject() and ChromeMSVSSolution()
wrappers to chromium_builders.py, that gate the underlying call to
the env.MSVS*() builders based on whether env.Bit('msvs') is set
(i.e., we're in --mode=msvs).
* Remove platform-specific gating of to-be-ported .scons files that we
now need to load on any platform to generate coheren MSVS files.
Move the env.Bit('windows') tests for actually building their
executables into the individual .scons files.
Review URL: http://codereview.chromium.org/14472
git-svn-id: http://src.chromium.org/svn/trunk/src/build@7297 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
and better-thought-out Hammer env.Bits() idioms:
* env['PLATFORM'] == 'win32' => env.Bit('windows')
* env['PLATFORM'] == 'posix' => env.Bit('linux')
* env['PLATFORM'] == 'darwin' => env.Bit('mac')
New idioms:
* env.Bit('posix') => really does mean "any POSIX platform"
* env.AnyBits('mac', 'linux') => specifically mac or linux, excluding
other POSIX platforms
Where we were using compound conditionals (e.g., "env['PLATFORM'] in
('posix', 'darwin')") I tried to take my best shot at translating
the intent (i.e., "env.Bits('posix')" for something POSIX, "not
env.Bits('mac')" for something not yet ported to Mac, etc.)
Review URL: http://codereview.chromium.org/15051
git-svn-id: http://src.chromium.org/svn/trunk/src/build@7270 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
* New _Node_MSVS.py module (from rspangler) with new MSVSFolder(),
MSVSProject() and MSVSSolution() Nodes. This will eventually
become a new SCons/Node/MSVS.py module in upstream SCons.
* New MSVSNew.py Tool module imports MSVS.py (either from SCons.Node
or from our temporary _Node_MSVS.py module) and attaches the
appropriate environment methods.
* MSVSSolution().Write() will generate a solution file based on
explicit configuration in the SConscript files.
* While we're here, define $SQLITE_DIR, which will be used by
the next checkins.
Review URL: http://codereview.chromium.org/14467
git-svn-id: http://src.chromium.org/svn/trunk/src/build@7120 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
We keep the current behavior for regular builds:
- debug: DCHECKS enabled.
- release: DCHECKS present but inactive; can be activated through the command line.
Now we add a new behavior for official builds:
- dchecks optimized away.
B=4555
Review URL: http://codereview.chromium.org/13231
git-svn-id: http://src.chromium.org/svn/trunk/src/build@6830 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
We had a bug where we weren't setting the fontdata for missing glyphs to
NULL. This caused WebKit not to try to load other fonts when glyphs
were missing.
With that fixed, we can implement the code to find a font for a given
set of code points. This uses fontconfig as it has this information
already indexed.
This fixes css2.1/t0805-c5519-brdr-r-00-a.html
Review URL: http://codereview.chromium.org/13108
git-svn-id: http://src.chromium.org/svn/trunk/src/build@6328 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
$BUILD_TARGET_DIR, so it can be set to "Debug" or "Release' to
mimic Visual Studio, or whatever other subdirectory the user prefers.
Fix PROGRESS= on Linux so the messages go to /dev/tty.
Remove the now-unnecessary in-SCons support for --clobber.
Review URL: http://codereview.chromium.org/13087
git-svn-id: http://src.chromium.org/svn/trunk/src/build@6301 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
* Configurable CHROME_BUILD_TYPE command line or external environment
variable for selecting appropriate release_impl*.scons settings
(_checksenabled, _coverage, _dom_stats, _official, _purify).
* Configurable CHROMIUM_BUILD command line or external environment
variable for selecting appropriate chromium_build*.scons settings
(_google_chrome).
* Configurable /INCREMENTAL linking via command line or external
environment variable ($INCREMENTAL), through appropriate setting
of an internal $CHROMIUM_INCREMENTAL_FLAGS construction variable.
* Full link of release builds by default.
* Alphabetize *.scons files in the mac_env.FilterOut() list.
* Explicitly set _checksenabled.scons link flags.
Review URL: http://codereview.chromium.org/13039
git-svn-id: http://src.chromium.org/svn/trunk/src/build@6210 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
deanm@chromium.org
maruel@chromium.org
thomasvl@chromium.org
mark@chromium.org
ager@google.com
dkegel@google.com
sgk@google.com
tc@google.com
brettw@chromium.org
estade@chromium.org
scherkus@chromium.org
jungshik@google.com
evanm@google.com
phajdan.jr@chromium.org
bradnelson@chromium.org
rvargas@google.com
mpcomplete@chromium.org
agl@chromium.org
avi@google.com
dank@chromium.org