Initial generation of native Visual Studio solution files...

Initial generation of native Visual Studio solution files
(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.



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

[sgk, 2008-12-16 19:47:26]

In particular, please take a look at the configuration in the *_sln.scons files.
 If you see anything that looks difficult to configure, now's the time to make
API changes.

[sgk, 2008-12-17 22:22:00]

Still looking for a review from one of you here...

[Nicolas Sylvain, 2008-12-17 23:37:59]

Sorry for the delay.

Why do we have base.vcproj and v8_base.vcproj?

http://codereview.chromium.org/14472/diff/188/254
File base/base_lib.scons (right):

http://codereview.chromium.org/14472/diff/188/254#newcode219
Line 219: env.MSVSProject('$BASE_DIR/build/base.vcproj',
what is this "build" directory?

http://codereview.chromium.org/14472/diff/188/252
File base/base_unittests.scons (right):

http://codereview.chromium.org/14472/diff/188/252#newcode156
Line 156: guid='{27A30967-4BBA-48D1-8522-CDE95F7B1CEC}')
What is this guid exactly? Is it required? Can we just randomize one?

http://codereview.chromium.org/14472/diff/188/245
File build/SConscript.v8 (right):

http://codereview.chromium.org/14472/diff/188/245#newcode90
Line 90: env.MSVSProject('$V8_DIR/tools/visual_studio/v8.vcproj',
Any change we can actually write the vcproj in the code directly, like where it
is right now? We could check them in too.

http://codereview.chromium.org/14472/diff/188/259
File chrome/test/activex_test_control/activex_test_control.scons (right):

http://codereview.chromium.org/14472/diff/188/259#newcode49
Line 49:
env.MSVSProject('$CHROME_DIR/test/activex_test_control/activex_test_control.vcproj',
do you care about going over 80n chars in the scons file?

[sgk, 2008-12-18 18:40:24]

base.vcproj build base.lib, v8_base.vcproj builds a specific subset ("base") of
v8 for Chromium use, it's not in v8.  It dates from before the V8 folks changed
their build configuration most recently.  I'd like for us to get ride of v8_base
and only use a build configuration that V8 itself supplies, but that's outside
the scope of this particular CL.

http://codereview.chromium.org/14472/diff/188/254
File base/base_lib.scons (right):

http://codereview.chromium.org/14472/diff/188/254#newcode219
Line 219: env.MSVSProject('$BASE_DIR/build/base.vcproj',
On 2008/12/17 23:37:59, Nicolas Sylvain wrote:
> what is this "build" directory?

We currently have all our .vcproj files in base underneath base\build.  This is
just replicating the current directory layout.

http://codereview.chromium.org/14472/diff/188/252
File base/base_unittests.scons (right):

http://codereview.chromium.org/14472/diff/188/252#newcode156
Line 156: guid='{27A30967-4BBA-48D1-8522-CDE95F7B1CEC}')
On 2008/12/17 23:37:59, Nicolas Sylvain wrote:
> What is this guid exactly? Is it required? Can we just randomize one? 

The underlying code supports either generating a randomized one or passing in a
hard-coded one like we're doing here.  I've hard-coded all of these for now so
that the new, generated files match our current, checked-in files.  This
minimizes the diffs so we can tell if there are any substantive changes that
have been introduced.  If we used randomized GUIDs right now, then it would be
hard to identify a missing project (e.g.) without either a laborious by-hand
comparison, or without some diff tool that would canonicalize the GUIDs anyway.

Note that if we want to check in the generated files, we'll probably want to
nail down GUIDs like this so people can actually read the CL diffs...

http://codereview.chromium.org/14472/diff/188/245
File build/SConscript.v8 (right):

http://codereview.chromium.org/14472/diff/188/245#newcode90
Line 90: env.MSVSProject('$V8_DIR/tools/visual_studio/v8.vcproj',
On 2008/12/17 23:37:59, Nicolas Sylvain wrote:
> Any change we can actually write the vcproj in the code directly, like where
it
> is right now? We could check them in too.

We'll need to generate it in the build directory (so that all the relative paths
end up correct in the generated file), but then copy it into the current code
location.  That's what's currently coded for the .sln files.

http://codereview.chromium.org/14472/diff/188/259
File chrome/test/activex_test_control/activex_test_control.scons (right):

http://codereview.chromium.org/14472/diff/188/259#newcode49
Line 49:
env.MSVSProject('$CHROME_DIR/test/activex_test_control/activex_test_control.vcproj',
On 2008/12/17 23:37:59, Nicolas Sylvain wrote:
> do you care about going over 80n chars in the scons file?

Done.

I went through and fixed other > 80 char lines, too.

[sgk, 2008-12-19 08:09:47]

Another review copy with updates so that --mode=dbg continues to build on Linux.
 This mainly involved setting up --mode=msvs in build/SConscript.main, making
sure we load up all the .scons files, and moving "if env.Bits()" checks for
things that still don't build on LInux (or Mac) inside the individual *.scons
files.

TBR since the basic structure of this has already been reviewed, but you can
check the differences against Patch 2 or 3 to see if the changes are okay.