Immediately after doing a full build I frequently find that ninja thinks that the build is not entirely clean. Twice this has been because views_content_client.dll is built after chrome.7z, despite being incorporated into chrome.7z. The file dates from the most recent build are:
06/03/2016 12:11 PM 1,414,328,526 chrome.7z
06/03/2016 12:13 PM 48,974,848 views_content_client.dll
06/03/2016 12:13 PM 3,918 views_content_client.dll.exp
06/03/2016 12:13 PM 7,530 views_content_client.dll.lib
06/03/2016 12:13 PM 150,532,096 views_content_client.dll.pdb
06/03/2016 12:13 PM 213,634,488 views_content_client.ilk
The data in .ninja_log agrees that chrome.7z was built first, and was only built once in the most recent build.
2967251 2988317 0 chrome.7z 4c1ae7a8c32b7c3c
3104473 3121145 0 views_content_client.dll 1dd74aff1c80d905
3104473 3121145 0 views_content_client.dll.lib 1dd74aff1c80d905
My args.gn settings are:
is_component_build = true
is_debug = true
is_win_fastlink = true
target_cpu = "x64"
is_syzyasan = false
is_chrome_branded = false
The ninja -d explain output is:
> ninja -d explain -v -n -C out\Debug_gn_component
ninja: Entering directory `out\Debug_gn_component'
ninja explain: restat of output chrome.7z older than most recent input ../Debug_gn_component/views_content_client.dll (0 vs 486684437)
ninja explain: chrome.7z is dirty
ninja explain: setup.ex_ is dirty
ninja explain: gen/chrome/installer/mini_installer/packed_files.rc is dirty
ninja explain: obj/chrome/installer/mini_installer/archive.stamp is dirty
ninja explain: gen/chrome/installer/mini_installer/packed_files.rc is dirty
ninja explain: obj/chrome/installer/mini_installer/mini_installer/packed_files.res is dirty
ninja explain: mini_installer.exe is dirty
ninja explain: obj/chrome/installer/mini_installer/archive.stamp is dirty
ninja explain: mini_installer.exe is dirty
ninja explain: obj/chrome/installer/mini_installer/next_version_mini_installer.inputdeps.stamp is dirty
ninja explain: next_version_mini_installer.exe is dirty
ninja explain: obj/chrome/installer/mini_installer/next_version_mini_installer.stamp is dirty
ninja explain: obj/both_gn_and_gyp.stamp is dirty
ninja explain: obj/gn_all.stamp is dirty
ninja explain: obj/All.stamp is dirty
ninja explain: obj/both_gn_and_gyp.stamp is dirty
ninja explain: mini_installer.exe is dirty
ninja explain: obj/chromium_builder_perf.stamp is dirty
ninja explain: obj/All.stamp is dirty
ninja explain: obj/chromium_builder_tests.stamp is dirty
ninja explain: obj/gn_all.stamp is dirty
ninja explain: obj/chrome/installer/mini_installer/archive.stamp is dirty
ninja explain: mini_installer.exe is dirty
ninja explain: obj/chrome/installer/mini_installer/next_version_mini_installer.stamp is dirty
Comment 1 by brucedaw...@chromium.org
, Jun 3 2016Status: Duplicate (was: Assigned)
I found the problem. The --depfile option to create_installer_archive.py creates an archive.d file which then becomes a dependency to chrome.7z. In component builds we package up all DLLs that aren't black listed: build_dlls = glob.glob(os.path.join(build_dir, '*.dll')) and a views_content_client.dll from a previous build will be sucked in and will become a dependency. Closing as duplicate. Will fix.