Generate all chrome .vcproj files:

Generate all chrome .vcproj files:

* 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)
  

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=8253

[sgk, 2009-01-12 21:29:53]

WebKit .vcproj generation to follow.  Similar to the last round:

* If you don't want to completely rubber-stamp this, please take a look at some
(or all) of the *.scons files to get a feel for what the definitions look like
and to suggest changes.
* The goal here is producing as-close-as-possible copies of our existing .vcproj
files.
* The CL description lists the differences in generated .vcproj files.
* There's more manual configuration than there will be in the final product.
* Specific planned cleanups /finishing touches currently include:
  ** Get rid of the by-hand MSVSFilter() calls in the file lists in favor of
generating a hierarchy that matches the file system.
  ** Get rid of the duplicated tools=[] lists in the MSVSProject() calls, in
favor of pulling standard lists from the construction environment and just
overriding any that matter.
  ** Add .scons files themselves to the projects.
  ** Add project(s) for re-generating the .vcproj / .sln files from within
Visual Studio itself.

[tony, 2009-01-13 00:40:40]

I looked at a few files and this LGTM.

As for the few differences, I bet they are vcproj files that were hand edited so
they have those small differences.  It might be worthwhile to go ahead and make
changes to make them more consistent (in a separate change).

On 2009/01/12 21:29:53, sgk wrote:
> WebKit .vcproj generation to follow.  Similar to the last round:
> 
> * If you don't want to completely rubber-stamp this, please take a look at
some
> (or all) of the *.scons files to get a feel for what the definitions look like
> and to suggest changes.
> * The goal here is producing as-close-as-possible copies of our existing
.vcproj
> files.
> * The CL description lists the differences in generated .vcproj files.
> * There's more manual configuration than there will be in the final product.
> * Specific planned cleanups /finishing touches currently include:
>   ** Get rid of the by-hand MSVSFilter() calls in the file lists in favor of
> generating a hierarchy that matches the file system.
>   ** Get rid of the duplicated tools=[] lists in the MSVSProject() calls, in
> favor of pulling standard lists from the construction environment and just
> overriding any that matter.
>   ** Add .scons files themselves to the projects.
>   ** Add project(s) for re-generating the .vcproj / .sln files from within
> Visual Studio itself.

[Nicolas Sylvain, 2009-01-13 01:06:19]

LGTM (mostly rubber stamped, but I took a quick look at all the files)

http://codereview.chromium.org/17603/diff/314/26
File chrome/app/theme/SConscript (right):

http://codereview.chromium.org/17603/diff/314/26#newcode53
Line 53: dest='$CHROME_SRC_DIR/chrome/app/theme/theme_dll.vcproj',
over 80 chars

[sgk, 2009-01-13 01:07:31]

http://codereview.chromium.org/17603/diff/314/26
File chrome/app/theme/SConscript (right):

http://codereview.chromium.org/17603/diff/314/26#newcode53
Line 53: dest='$CHROME_SRC_DIR/chrome/app/theme/theme_dll.vcproj',
On 2009/01/13 01:06:19, Nicolas Sylvain wrote:
> over 80 chars

Good point, thanks -- I need to make a pass through and fix these en masse
before checking in.

[sgk, 2009-01-17 01:25:12]

TBR: tony

TBR based on previous LGTM comments, try bot passing, and having caught up with
recent refactorings