Bug 1479540 - Accept "triplet" strings with only two parts in moz.configure. r=froydnj
authorChris Manchester <cmanchester@mozilla.com>
Tue, 31 Jul 2018 11:58:08 -0700
changeset 429416 36f4ba2fb6f5139b7942e81554190354da1f369a
parent 429415 ff18e94c90460faa9cca8ff39a0ea4876b0c2039
child 429417 df453510ba5512b30501b0eb1c9031035981cea8
push id67142
push usercmanchester@mozilla.com
push dateTue, 31 Jul 2018 19:04:59 +0000
treeherderautoland@36f4ba2fb6f5 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersfroydnj
bugs1479540
milestone63.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 1479540 - Accept "triplet" strings with only two parts in moz.configure. r=froydnj MozReview-Commit-ID: 7pFhoJgBMhQ
build/moz.configure/init.configure
--- a/build/moz.configure/init.configure
+++ b/build/moz.configure/init.configure
@@ -587,17 +587,26 @@ option('--target', nargs=1,
 @imports(_from='__builtin__', _import='KeyError')
 @imports(_from='__builtin__', _import='ValueError')
 def split_triplet(triplet, allow_unknown=False):
     # The standard triplet is defined as
     #   CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
     # There is also a quartet form:
     #   CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
     # But we can consider the "KERNEL-OPERATING_SYSTEM" as one.
-    cpu, manufacturer, os = triplet.split('-', 2)
+    # Additionally, some may omit "unknown" when the manufacturer
+    # is not specified and emit
+    #   CPU_TYPE-OPERATING_SYSTEM
+    parts = triplet.split('-', 2)
+    if len(parts) == 3:
+        cpu, _, os = parts
+    elif len(parts) == 2:
+        cpu, os = parts
+    else:
+        die("Unexpected triplet string: %s" % triplet)
 
     # Autoconf uses config.sub to validate and canonicalize those triplets,
     # but the granularity of its results has never been satisfying to our
     # use, so we've had our own, different, canonicalization. We've also
     # historically not been very consistent with how we use the canonicalized
     # values. Hopefully, this will help us make things better.
     # The tests are inherited from our decades-old autoconf-based configure,
     # which can probably be improved/cleaned up because they are based on a