Bug 1527371 - Show linker time breakdown for xul.dll r=froydnj
authorDavid Major <dmajor@mozilla.com>
Fri, 31 May 2019 17:13:34 +0000
changeset 476623 23f5c0544d7bd2e6ceab83657a63e85c9c95ff85
parent 476622 0aa99f6f8cc45867d0eac47e86970874d5917a85
child 476624 038735236230fe6c9137006418352c852fd4c199
push id36104
push usercbrindusan@mozilla.com
push dateTue, 04 Jun 2019 03:45:41 +0000
treeherdermozilla-central@38c2478a4825 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersfroydnj
bugs1527371
milestone69.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1527371 - Show linker time breakdown for xul.dll r=froydnj COFF-flavored lld collects timing stats about various phases of linking. This might be useful to have in logs. I left it off in developer builds to avoid spamming tight edit-compile cycles. Differential Revision: https://phabricator.services.mozilla.com/D33319
toolkit/library/moz.build
--- a/toolkit/library/moz.build
+++ b/toolkit/library/moz.build
@@ -53,16 +53,20 @@ def Libxul(name, output_category=None):
             '/xpcom/base',
         ]
         # config/version.mk says $(srcdir)/$(RCINCLUDE), and this needs to
         # be valid in both toolkit/library and toolkit/library/gtest.
         # Eventually, the make backend would do its own path canonicalization
         # and config/version.mk would lift the $(srcdir)
         RCINCLUDE = '$(DEPTH)/toolkit/library/xulrunner.rc'
 
+    # Show a breakdown of linker time. (Too verbose for local builds.)
+    if CONFIG['CC_TYPE'] == 'clang-cl' and not CONFIG['DEVELOPER_OPTIONS']:
+        LDFLAGS += ['-time']
+
     Libxul_defines()
 
     if CONFIG['MOZ_NEEDS_LIBATOMIC']:
         OS_LIBS += ['atomic']
 
     # TouchBar-related classes are only available in the 10.12.2 SDK and later.
     # We need to weak link these classes until we've upgraded our SDK to at
     # least 10.12.2.