| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Path name translation (/ to \) of various MSVSTool attributes.
* Explicit keyword= arguments to MSVSProject. This will likely
go away eventually in favor of uniform behavior.
* Add a relative_path_substitutions array that can be used
to substitute in Visual Studio variable like $(OutDir).
* Add a local_directory_prefix that can be set to './' to only
affect files in the current directory.
* Additional Keyword ordering in Tool attributes to continue to
match the default order Visual Studio generates.
* Add a Derived() proxy class that can wrap a File node to tell
the .vcproj generation that we want the derived file, not its
source(s), in the file list.
* In the individual *.scons files, add the necessary files (mostly
.h files) to file lists, and update MSVSProject() calls with
the additional necessary information.
Result is identical .vcproj files modulo the following differences:
* Four locales .vcproj files (da, en-US, he and zh-TW) with
source file orders that don't match the other locale .vcproj
files have re-ordered file lists to match the rest.
* Cosmetic XML changes (white space, ending tags) in:
chrome/app/chrome_dll.vcproj
chrome/app/generated_resources.vcproj
net/build/net_resources.vcproj
* Removal or addition of ./ prefixes from various files that don't
match the other file specifications within their individual
.vcproj files:
chrome/installer/util/util.vcproj
net/build/net.vcproj
net/build/net_unittests.vcproj
* Add missing empty sections (<ToolFiles>, <References>, <Globals>)
for consistency with other .vcproj files:
chrome/tools/test/image_diff/image_diff.vcproj
third_party/libpng/libpng.vcproj
third_party/zlib/zlib.vcproj
* Add missing RootNameSpace attribute:
chrome/test/automation/automation.vcproj
testing/gtest.vcproj
* Use && instead of \r\n as a command separator, to sidestep
XML-generation problems:
chrome/app/chrome_exe.vcproj
* Remove unnecessary (?) duplicate files in the file list:
chrome/browser/views/browser_views.vcproj
(event_utils.cc and event_utils.h were duplicated)
Review URL: http://codereview.chromium.org/17603
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8253 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
Review URL: http://codereview.chromium.org/17353
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7939 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
recent changes and get rid of cut-and-paste:
* Add generation of the new net_resource.vcproj file.
* Accomodate the net\net.vsprops file.
* New base.vcproj dependency in activex_shim_dll.vcproj.
* New tld_cleanup.vcproj dependency in net.vcproj.
* New ondemand_updates.vcproj dependencies in
gcapi_{dll,lib}.vcproj.
* Re-order dump_cache.vcproj dependencies to match new
checked-in solutions.
* New input file directory layout in zlib (minizip folder)
and testing\gtest (hierarchy).
* Use a new dest= argument to ChromeMSVSSolution()
and ChromeMSVSProject() to get rid of cut-and-pste
installation code, and provide a central point for
controlling when/whether we want to generate the files
only under the build directory, or drop them in place
for checking in.
* Comment out an unnecessarily verbose warning if the
buildtarget is executed with an action that we don't
map to specific Visual Studio settings. Sometimes
this is normal and okay, but the warning should get
restored at some point when we work out the precise
conditions under which it makes sense.
Review URL: http://codereview.chromium.org/17602
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7856 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generation of net .vcproj and .sln files.
Specific changes:
* Add to MSVSProject() calls: GUID, input_files list,
tools list (that are common to the individual configurations).
* Add *.h files and MSVSFilter() hierarchies to input_files lists.
* Switch to using the .Remove() method for instead of by-hand
Python to remove things from input_files lists.
* Use of precompiled header files still requires separate by-hand
Configuration specifications.
* Remove .dat files from the input file lists when compiling.
* Extensive _Node_MSVS.py changes that set us up for deducing this
information from parallel Debug and Release builds instead of
configuring things by hand, basically by delaying evaluation of
most of the strings, then introspecting on the command lines
that will be used to generate the targets and translating
compiler and linker options into Visual Studio settings.
The result is (again) byte-for-byte identical .vcproj files, modulo
removal of a ".\" current-directory prefix for a few RelativePath
specifications.
Review URL: http://codereview.chromium.org/17478
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7854 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
Review URL: http://codereview.chromium.org/17327
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7830 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specific changes:
* Add to MSVSProject() calls: GUID, input_files list,
tools list (that are common to the individual configurations).
* Add *.h files and MSVSFilter() hierarchies to input_files lists.
* Switch to using the .Remove() method for instead of by-hand
Python to remove things from input_files lists.
* Use of precompiled header files still requires separate by-hand
Configuration specifications.
* Remove .dat files from the input file lists when compiling.
* Extensive _Node_MSVS.py changes that set us up for deducing this
information from parallel Debug and Release builds instead of
configuring things by hand, basically by delaying evaluation of
most of the strings, then introspecting on the command lines
that will be used to generate the targets and translating
compiler and linker options into Visual Studio settings.
The result is (again) byte-for-byte identical .vcproj files, modulo
removal of a ".\" current-directory prefix for a few RelativePath
specifications.
Review URL: http://codereview.chromium.org/17436
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7826 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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: svn://svn.chromium.org/chrome/trunk/src@7297 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: svn://svn.chromium.org/chrome/trunk/src@7270 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
build\*.scons structure (mirroring build\*.vsprops files):
* Use env.ApplySConscript() instead of env.SConscript with a
hand-crafted dictionary defining 'env'.
* Move various CPPPATH, CCFLAGS, CPPDEFINES, LIBS and LIBPATH
definitions from build/SConscript.main and target-specific
*.scons files into the build\*.scons files that mirror the
existing build\*.vsprops hierarchy.
* Use the new build\{debug,release}.scons files to update the
windows_dbg and windows_opt construction environments.
* Mirror current support for CHROME_BUILD_TYPE and CHROMIUM_BUILD
external environment variables.
* Remove hard-coded /TP options.
* Massage $CXXFLAGS to remove $CCFLAGS, avoiding duplication of options
on command lines. Handle the ripple effect in $PCHCOM by adding
$CCFLAGS back to that command line.
* Delete hammer's default settings of {CC,LINK}FLAGS_{DEBUG,OPTIMIZED}
so they don't pollute our construction environments.
* Update chrome config to link against v8 for opt, v8_g for dbg.
* Get rid of fragile by-hand order of using_net.scons before other
using_*.scons files. We're now using --start-group and --end-group
on Linux to deal with dependency cycles in libraries.
Review URL: http://codereview.chromium.org/11478
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5741 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
base/third_party/dmg_fp and compile it into base_lib.
Review URL: http://codereview.chromium.org/10769
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5521 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
tbr=evan
Review URL: http://codereview.chromium.org/10664
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5324 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
in base, net and sandbox:
* Remove by-hand Install() and Alias() calls.
* Set $COMPONENT_PROGRAM_GROUPS and $COMPONENT_TEST_PROGRAM_GROUPS
(with in each foo\foo.scons file) so executables get added
automatically to the appropriate Alias.
* Set $TESTS_DIR and $STAGING_DIR so executables get linked
directly in their final resting place ($TARGET_ROOT).
Review URL: http://codereview.chromium.org/9188
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4805 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
This will facilitate changing where the main sconstruct lives.
Review URL: http://codereview.chromium.org/7847
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3725 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
* Rename SConscript files to {module}.scons or {moduel}_lib.scons,
depending on the primary target involved.
* Separate targets into individual *.scons files, with one
construction environment (named "env") per *.scons file.
* Add using_{module}.scons files (like .vsprops) that will be used
by other modules to add CPPDEFINES, CPPPATH, LIBS and LIBPATH values.
* Update other modules' *.scons files to use the new using_{module}.scons
files (using a temporary one-liner idiom until we have the
ApplySConscript() method from the Hammer modules).
* Use the idiom of removing to-be-ported files from the master list,
so they can be simply deleted from the to-be-ported list as they
get ported in the future, instead of having to shuffle entries
between lists.
* Use $OBJ_ROOT instead of hard-coded '#/$BUILD_TYPE/' for the $*_DIR
variables.
* Add a addRepository() call mapping build/ to $TARGET_ROOT/googleurl,
so its $OBJ_ROOT value can look like the others'.
* Formatting changes, primarily modifying indentation to conform to
style guidelines.
* Fix copyright headers in some third_party/* modules
previously overlooked.
* Add rudimentary __doc__ strings, setting up for a future
ability to generate meaningful documentation.
Review URL: http://codereview.chromium.org/7807
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3675 0039d316-1c4b-4281-b951-d872f2087c98
|
