Build chrome.exe into intermediate dir then copy it to output dir.

BUG=92528
Build chrome.exe into intermediate dir then hard-link it into the output dir.

This allows for incremental linking of both chrome.exe and chrome.dll; otherwise, their incremental link files collide as $(OutDir)/chrome.ilk

There are some drawback/caveats to this approach.

1. Post-build steps are not always run.  For example, if you do a project-only, relink on the project it seems to relink, but not run the post-build step.

2. On filesystems that don't support linking, it falls back to a copy which is a bit wasteful, but it's only applied to the chrome.exe target, not the dll target, so it's only 4 MB (as opposed to ~165MB) in Debug mode.

Another approach to doing this in the gyp files would be to introduce an intermediate step for chrome.exe and turn the current chrome target into a copy step (which should get rid of any flakiness in post-build approach).

[Roger McFarlane (Google), 2011-08-12 18:40:27]

PTAL

http://codereview.chromium.org/7634025/diff/6001/chrome/chrome_exe.gypi
File chrome/chrome_exe.gypi (right):

http://codereview.chromium.org/7634025/diff/6001/chrome/chrome_exe.gypi#newco...
chrome/chrome_exe.gypi:461: 'XCOPY /Y /F /R /K /I "$(IntDir)\\chrome.exe"
"$(OutDir)"',
Linking isn't supported on Windows XP (which is the published minimum supported
Windows OS version) so we do a copy instead of making a link (mklink is build
into Vista and above).

http://www.chromium.org/developers/how-tos/build-instructions-windows#TOC-Pre...

[Roger McFarlane (Google), 2011-08-12 20:35:02]

PTA(nother)L

http://codereview.chromium.org/7634025/diff/6001/chrome/chrome_exe.gypi
File chrome/chrome_exe.gypi (right):

http://codereview.chromium.org/7634025/diff/6001/chrome/chrome_exe.gypi#newco...
chrome/chrome_exe.gypi:461: 'XCOPY /Y /F /R /K /I "$(IntDir)\\chrome.exe"
"$(OutDir)"',
On 2011/08/12 18:40:33, Roger McFarlane (Google) wrote:
> Linking isn't supported on Windows XP (which is the published minimum
supported
> Windows OS version) so we do a copy instead of making a link (mklink is build
> into Vista and above).
> 
>
http://www.chromium.org/developers/how-tos/build-instructions-windows#TOC-Pre...

Muahahaha ... tools\build\win\hardlink_failsafe.bat

[scottmg, 2011-08-12 23:06:42]

On 2011/08/12 20:35:02, Roger McFarlane (Google) wrote:
 
> Muahahaha ... tools\build\win\hardlink_failsafe.bat

Excellent, confirmed that it works for me and I can get incremental linking
again. Thanks Roger.

2>------ Build started: Project: chrome_dll, Configuration: Debug Win32 ------
2>Linking...
...
2>Build Time 0:14

w00t!

[Roger McFarlane (Google), 2011-08-13 01:28:37]

Need an L.G.T.M. from an owner, plz.

[M-A Ruel, 2011-08-13 01:31:02]

I wouldn't be surprised if it breaks VS2010.

I'm sorry I don't have a vs2010 try bot though.

lgtm if it works.

[Roger McFarlane (Google), 2011-08-13 02:57:24]

On 2011/08/13 01:31:02, Marc-Antoine Ruel wrote:
> I wouldn't be surprised if it breaks VS2010.
> 
> I'm sorry I don't have a vs2010 try bot though.
> 
> lgtm if it works.

Hey Scott! Are you using vs 2008 or 2010? (I'm using 2008)

[scottmg, 2011-08-13 03:24:35]

On 2011/08/13 02:57:24, Roger McFarlane (Google) wrote:
> Hey Scott! Are you using vs 2008 or 2010? (I'm using 2008)

I'm on 2008 too. It does appear it'll break msbuild/2010 though. :( Looks like
gyp on msbuild/2010 needs some work still, from msvs.py:

  # TODO(jeanluc) Validate & warn that we don't translate
  # prebuild = configuration.get('msvs_prebuild')
  # postbuild = configuration.get('msvs_postbuild')

So we'll probably just end up with an exe in $(IntDir) on 2010. Is there a gyp
variable/condition to distinguish 2008/2010? Getting a bit hairy, but maybe only
do the $(IntDir) + hardlink on 2008 if possible?

[scottmg, 2011-08-13 05:47:10]

Oh, it does appear that Custom Build Steps ("actions" maybe?) are working on
both 2008/2010. I don't have 2010 to test though.

Perhaps that would be a better approach anyway, as I believe it would fix the
"Post-build steps are not always run" problem.

[scottmg, 2011-08-14 05:46:25]

Some more info on that idea... I briefly tried getting an 'actions' block
working. i.e.

          'msvs_settings': {
            'VCLinkerTool': {
              'ImportLibrary': '$(OutDir)\\lib\\chrome_exe.lib',
              'ProgramDatabaseFile': '$(OutDir)\\chrome_exe.pdb',
              'OutputFile': '$(IntDir)\\chrome.exe',
            },
          },
          # Linking to $(IntDir) and then linking back to $(OutDir) is a
          # workaround to avoid having the .ilk files for chrome.dll and
          # chrome.exe conflicting. http://crbug.com/92528
          'actions': [
          {
              'action_name': 'hardlink_to_outdir',
              'message': 'Hardlinking chrome.exe to $(OutDir)\\chrome.exe...',
              'inputs': [
                  '$(IntDir)\\chrome.exe',
              ],
              'outputs': [
                  '$(OutDir)\\chrome.exe',
              ],
              'action': ['cmd.exe', '/c',
'tools\\build\\win\\hardlink_failsafe.bat', '$(IntDir)\\chrome.exe',
'$(OutDir)\\chrome.exe'],
          },
          ],

(had to add cmd.exe in front to workaround gyp always running via cygwin/bash)

Unfortunately this doesn't work (though it's close). It does the hardlink before
running the linker. I'm not sure why. I guess it's something to do with it not
correctly interpreting the inputs and outputs so it doesn't know the link is a
prerequisite to running the for some reason (maybe someone sees the error?).

I'm not sure this is a better approach now even if working. It might be simpler
to enlist someone's support for getting msvs_postbuild to work in 2010 instead.

[Roger McFarlane (Chromium), 2011-08-17 13:42:21]

Subsumed by http://codereview.chromium.org/7633024/