)]}'
{
  "commit": "1967621cc9498a4d775a8a9eaabbcb7a52be8316",
  "tree": "5cebf96038d7ee686c14aeffa3c854428e30543b",
  "parents": [
    "a43c76dbe30d619188dc685b7d432a92e7c2b66b"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Wed Jan 25 10:03:53 2023 -0500"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Thu Jan 26 22:55:32 2023 +0000"
  },
  "message": "Reduce architecture detection in CMake.\n\nThis follows up on\nhttps://boringssl-review.googlesource.com/c/boringssl/+/55626, to make\nthe CMake build rely on the C preprocessor, rather than CMake. While not\nas disasterous as pre-@platforms Bazel, CMake\u0027s build-level platform\nselection is not ideal:\n\n- CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names\n  for the same architecture, and sometimes, e.g., building for 32-bit\n  Windows will still report \"AMD64\".\n\n- On Apple platforms, there is a separate and technically multi-valued\n  CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but\n  don\u0027t support the multi-value case.\n\nInstead, broadly detect whether we expect gas or nasm, and then pull in\nevery matching file, relying on the C preprocessor to exclude files as\nneeded. This also fixes a quirk in generate_build_files.py, where it\nneeded to use the filename to detect the architecture of a perlasm\nscript in CMake.\n\nThis CL only applies to the standalone CMake build. The generated file\nlists do not change. I\u0027m not sure yet whether this strategy will be\nappropriate for all those builds, so this starts with just the CMake\none.\n\nThis hits a pair of nuisances with the Apple linker. First, Apple has\ntwo ways to invoke the linker. The new way is libtool, the old way is\nranlib. Warnings are different between the two.\n\nIn both libtool and ranlib, for x86_64 but not aarch64, we get a warning\nabout files with no symbols. This warning fires for us, but this change\nmakes it much, much noisier. Oddly, this warning does not trigger when\nbuilding for aarch64, just x86_64. I\u0027m not sure whether this is because\naarch64 hits new behavior or it happens that aarch64 object files always\ncontain some dummy symbol.\n\nlibtool has a -no_warning_for_no_symbols flag to silence this warning.\nUnfortunately, CMake uses ranlib and there is no way, from what I can\ntell, to pass this flag to ranlib. See\nhttps://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698\n\nSince this seems to be a broader CMake limitation, and we were already\nliving with some of these warnings, I\u0027ve left this alone. But this CL\ndoes make macOS x86_64 CMake builds very noisy.\n\nI haven\u0027t used it here, but LLVM has a pile of CMake goo that switches\nCMake to using libtool and passes in that flag. Trialing it out reveals\n*different* issue, which I have worked around:\n\nWhen invoked as libtool, but not as ranlib, the Apple linker also warns\nwhen two object files have the same name. This appears to be a holdover\nfrom static libraries using ar, even though ld does not actually invoke\nar. There appears to be no way to suppress this warning.\n\nThough we don\u0027t use libtool, we can probably assume most non-CMake\nbuilds will be using the modern spelling. So I\u0027ve suffixed each perlasm\nfile with the OS. This means, in generate_build_files.py, we no longer\nneed a separate directory for each platform. For now, I\u0027ve kept that\nalone, because some update scripts rely on that spelling to delete old\nfiles.\n\nUpdate-Note: If the CMake build fails to build somewhere for an\nassembly-related reasons, it\u0027s probably from this CL.\n\nBug: 542\nChange-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "7e5a64899ee4d6cc4927f2ee1f9a188185e5fffb",
      "old_mode": 33188,
      "old_path": "CMakeLists.txt",
      "new_id": "4c39d126650bb168130561223c23b3b61d56a92f",
      "new_mode": 33188,
      "new_path": "CMakeLists.txt"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "b9530cfbc27adf4d316885b1783272aa2cdfde84",
      "new_mode": 33188,
      "new_path": "cmake/perlasm.cmake"
    },
    {
      "type": "modify",
      "old_id": "17174431b9897c0bbd312f3999c0592bf55f797a",
      "old_mode": 33188,
      "old_path": "crypto/CMakeLists.txt",
      "new_id": "e1634a4faaa6e64a3c2afda4a980ff1344f1b72d",
      "new_mode": 33188,
      "new_path": "crypto/CMakeLists.txt"
    },
    {
      "type": "modify",
      "old_id": "52b094237a162d789bf1b0abb53552ef051f771d",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/CMakeLists.txt",
      "new_id": "82505b742cf7d19c9438891fa35ecf91f1a36dbe",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/CMakeLists.txt"
    },
    {
      "type": "modify",
      "old_id": "5a19c920d560b0ef85673e2738737170495aeddf",
      "old_mode": 33188,
      "old_path": "util/generate_build_files.py",
      "new_id": "4a93a7fc887d071d02a284bc1234a577a4495cbe",
      "new_mode": 33188,
      "new_path": "util/generate_build_files.py"
    }
  ]
}