Initial subset of .vcproj file generation, covering generation of:...

Initial subset of .vcproj file generation, covering generation of:
  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.

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

[sgk, 2008-12-23 05:00:44]

This starts with a manageable subset of the .vcproj files used to build base.  I
still have to add some that have specific Filter hierarchies.

The key sanity check I'd like from you all is the new code in the *.scons files:
 updates to calls to ChromeMSVSProject(), and AddConfig().  That's the general
outline of what this currently looks like in the configuration, and it would be
good to modify it now (if necessary).

[bradn, 2008-12-23 18:20:42]

LGTM

http://codereview.chromium.org/16447/diff/17/30
File base/base_lib.scons (right):

http://codereview.chromium.org/16447/diff/17/30#newcode384
Line 384: #    'debug_message.vcproj',
I assume this is something coming later?

[Nicolas Sylvain, 2008-12-23 20:23:38]

mostly rubber stamp lgtm

[sgk, 2008-12-24 03:19:32]

Updated with generation of the additional .vcproj files necessary for base
(skia.vcproj, icu.vcproj, icudt.vcproj, base_unittests.vcproj) and support for
their explicit MSVSFilter hierarchies.  This required some additional
refactoring in the emerging Node.MSVS hierarchy.

I'm going to TBR this, given the previous lgtm, the fact that it passes on all
architectures on the try server, the need to keep making progress, and the
general rubber-stampiness of this anyway.  Feedback still welcome, of course.

http://codereview.chromium.org/16447/diff/17/30
File base/base_lib.scons (right):

http://codereview.chromium.org/16447/diff/17/30#newcode384
Line 384: #    'debug_message.vcproj',
On 2008/12/23 18:20:42, bradn wrote:
> I assume this is something coming later?

Commented out before adding debug_message.vcproj to the list, now restored. 
Thanks.