Support Visual C++ PGO in Ninja generator

test/win/gyptest-link-ltcg.py

Index: test/win/gyptest-link-ltcg.py
===================================================================
--- test/win/gyptest-link-ltcg.py	(revision 0)
+++ test/win/gyptest-link-ltcg.py	(revision 0)
@@ -0,0 +1,42 @@
+#!/usr/bin/env python
+
+# Copyright (c) 2013 Google Inc. All rights reserved.
+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+"""
+Make sure LTCG setting is extracted properly.
+"""
+
+import TestGyp
+
+import sys
+import time
+
+if sys.platform == 'win32':
+  test = TestGyp.TestGyp(formats=['msvs', 'ninja'])
+
+  CHDIR = 'linker-flags'
+  test.run_gyp('ltcg.gyp', chdir=CHDIR)
+
+  if test.format == 'ninja':

[scottmg, 2013/11/23 17:15:13]

would it be possible to test some effect, rather than the contents of build
files so that ninja and msvs match? For PGI we could check that a .pgd file is
generated I guess. I'm not sure about PGO and PGU though, perhaps something that
the linker prints to stdout that identifies what it's doing?

[yukawa, 2013/11/25 14:04:12]

OK.  Added some working samples as pgo.gyp.  PTAL?

For PGI, this CL tests if *.pgd is generated.
For PGO, this CL tests if 'profiled functions' appears in the stdout during the
build.
For PGU, this CL tests the profile guided build succeeds or not even when some
*.cc is newer than *.pgd file. (This is what PGU is designed for)

The followings are notes about what I encountered. Hope this helps me again when
I use PGO in my project.

Firstly, Under some environment, PGO may not be supported. I simply skipped the
real test in such cases.

Secondary, executables build with PGI depend on some special DLLs installed
under '$(VCInstallDir)bin'.  To work around this, I added 'update_pgd.py' to set
up PATH environment variable before executing the instrumented binary.

Finally, executables build with PGI generate a *.pgc file where the profile data
is stored.  The problem here is that its file name is not deterministic.  This
makes it difficult to describe a correct dependency as a gyp 'action'.  In this
patch, I used my 'update_pgd.py' too to kick pgomgr.exe just after execution of
target binary so that merge all *.pgc data will be merged into single *.pgd
file, whose name is under our control.  This problem might also be solved by
copying the target executable into a separated temporary directory, then after
execution, rename *.pgc found in the directory to some deterministic one.

Anyway my lessons learned from this trial is that cyclic procedure implied from
profile guided build flow don't go along well with typical build systems, which
expect the dependency graph is directed and acyclic in general.  Build is hard.

+    def GetNinjaFile(ltcg_option):
+      return test.built_file_path('obj/test_ltcg_%s.ninja' % ltcg_option,
+                                  chdir=CHDIR)
+    test.must_not_contain(GetNinjaFile('default'), '/LTCG')
+    test.must_contain(GetNinjaFile('use'), '/LTCG')
+    test.must_contain(GetNinjaFile('instrument'), '/LTCG:PGINSTRUMENT')
+    test.must_contain(GetNinjaFile('optimize'), '/LTCG:PGOPTIMIZE')
+    test.must_contain(GetNinjaFile('update'), '/LTCG:PGUPDATE')
+  elif test.format == 'msvs':
+    def AssertLTCGOption(ltcg_option, value):
+      return test.built_file_path('test_ltcg_%s.vcxproj' % ltcg_option,
+                                  chdir=CHDIR)
+      LTCG_FORMAT = '<LinkTimeCodeGeneration>%s</LinkTimeCodeGeneration>'
+      test.must_contain(vcproj, LTCG_FORMAT % ltcg_option)
+    AssertLTCGOption('default', 'Default')
+    AssertLTCGOption('use', 'UseLinkTimeCodeGeneration')
+    AssertLTCGOption('instrument', 'PGInstrument')
+    AssertLTCGOption('optimize', 'PGOptimization')
+    AssertLTCGOption('update', 'PGUpdate')
+  test.pass_test()