)]}'
{
  "commit": "ac6cc95f4008e318945de4c15a13589f582f8e0e",
  "tree": "deac486caf6ccdfae51ce7c55d37fa88edcb1511",
  "parents": [
    "07f614a8db14f4af27b90ecf97266466cddfc838"
  ],
  "author": {
    "name": "Adrian Taylor",
    "email": "adetaylor@chromium.org",
    "time": "Sun Apr 26 20:49:18 2020 -0700"
  },
  "committer": {
    "name": "Commit Bot",
    "email": "commit-bot@chromium.org",
    "time": "Tue May 12 17:37:04 2020 +0000"
  },
  "message": "Allow rlib linking into C++ targets.\n\nPreviously, we assumed that the only way to link Rust rlibs into C++ was\nby having an intermediate Rust \"static library\" target, which is in\neffect a complete static library containing all the dependencies of that\nparticular Rust code (including transitive dependencies and the standard\nlibrary).\n\n  [rlibs] -\u003e [Rust staticlib] -\u003e [solink/link etc.]\n\nBut this doesn\u0027t work in cases where multiple Rust libraries may\nsometimes be linked in different permutations. In Chrome we have\njust that situation. In a debug build, Chrome exists as multiple\n.so files, whilst in a release build, it\u0027s linked into a single\nexecutable.\n\nDebug build:\n  [rlib A] -\u003e [Rust staticlib A] -\u003e [solink A]\n\n  [rlib B] -\u003e [Rust staticlib B] -\u003e [solink B]\n\nRelease build:\n  [rlib A] -\u003e [Rust staticlib A] -\\\n                                  |\n  [rlib B] -\u003e [Rust staticlib B] -+--\u003e [exe - violates ODR]\n\nThe ODR violations in producing the final linked product assume\nthere are bits of Rust stuff repeated across both staticlibs.\ne.g. bits of the Rust standard library. This would also happen\nif rlibs A and B both depended upon rlib C.\n\nFurthermore, these rlibs are so deeply nested in our dependency\ntree that they stand no realistic chance of determining whether\nthe final product is a single binary or several binaries. gn does\nnot encourage this kind of global knowledge anyway, and it feels wrong\nfor a distant rlib to make decisions based upon the final output.\n\nTherefore, we have switched to an alternative strategy where Rust rlibs\nare linked directly into the final C++ executables and shared objects,\ntogether with the Rust standard library and other dependencies which\nare normally inserted by rustc as it calls the linker.\n\nIn order to achieve this with gn, we need rlibs to be linked into C++\ntargets.\n\nInstead of including them directly into the {{inputs}} for a C++\nlink target, they\u0027re provided as a separate\n\n  rlibs \u003d ...\n\nsubstitution. This is because some toolchains may wish to treat them\ndifferently (for instance, not including them inside a\n-Wl,--whole-archive directive).\n\nThis should have no effect on projects using the former strategy\nof linking rlibs together into a static library, because that static\nlibrary should \"absorb\" its dependencies rather than passing them on\nto downstream C++ targets, and thus such dependencies should not be\nvisible to the Ninja C target writer.\n\nAn alternative would have been to place such rlibs within the existing\n\n  libs \u003d\n\nsubtitution; however, such entries are typically of the form \"-lfoo\"\nand are assembled from config directives rather than OutputFile paths.\n\nThis change doesn\u0027t deliberately change any behavior relating to\nRust procedural macros. It seems questionable to have any C++ targets\never depend directly on procedural macros; further work is required\nhere.\n\nChange-Id: I5fd81a872339e7334889fc3b73d346586163f0dc\nReviewed-on: https://gn-review.googlesource.com/c/gn/+/8260\nCommit-Queue: Brett Wilson \u003cbrettw@chromium.org\u003e\nReviewed-by: Petr Hosek \u003cphosek@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "2cdff65bb74d1d410c5a5e6623becd3151a1b3ea",
      "old_mode": 33188,
      "old_path": "docs/reference.md",
      "new_id": "afd928c7400819de93ccfde48805cfc405f52c90",
      "new_mode": 33188,
      "new_path": "docs/reference.md"
    },
    {
      "type": "modify",
      "old_id": "b21fea42800f0bc292aaf086651f151d5835d4e9",
      "old_mode": 33188,
      "old_path": "src/gn/c_substitution_type.cc",
      "new_id": "b9b7eba0e3301159d31941e3a61ec6c02732bb2c",
      "new_mode": 33188,
      "new_path": "src/gn/c_substitution_type.cc"
    },
    {
      "type": "modify",
      "old_id": "e95531219db174c2087fa2c6ca4e945d52f3c6bd",
      "old_mode": 33188,
      "old_path": "src/gn/c_substitution_type.h",
      "new_id": "d4ba60638f4ead64604b571c18616e5be45b1986",
      "new_mode": 33188,
      "new_path": "src/gn/c_substitution_type.h"
    },
    {
      "type": "modify",
      "old_id": "e5ddc5901eb91099f4bac757ec2630e1f93080b2",
      "old_mode": 33188,
      "old_path": "src/gn/function_toolchain.cc",
      "new_id": "8175c8d4396f4490499bb3e4f407f5fb9266bacd",
      "new_mode": 33188,
      "new_path": "src/gn/function_toolchain.cc"
    },
    {
      "type": "modify",
      "old_id": "5fa646fffd41aea79a5b3fe8089e8394c11d16b1",
      "old_mode": 33188,
      "old_path": "src/gn/ninja_c_binary_target_writer.cc",
      "new_id": "aba4b68974c79ef88cdefb6da1b0c3772311e397",
      "new_mode": 33188,
      "new_path": "src/gn/ninja_c_binary_target_writer.cc"
    },
    {
      "type": "modify",
      "old_id": "ee6b6ac3c592d666facb5d31355c9e7c567ab113",
      "old_mode": 33188,
      "old_path": "src/gn/ninja_c_binary_target_writer.h",
      "new_id": "d69baf20dc1eb7b0bfc1d0469bb2ee7bb70a7eee",
      "new_mode": 33188,
      "new_path": "src/gn/ninja_c_binary_target_writer.h"
    },
    {
      "type": "modify",
      "old_id": "6b0fd64e1ea1f849bfebecd618330265f3864160",
      "old_mode": 33188,
      "old_path": "src/gn/ninja_c_binary_target_writer_unittest.cc",
      "new_id": "315232bf9cd5d2325230d43c88b8910b426a7a85",
      "new_mode": 33188,
      "new_path": "src/gn/ninja_c_binary_target_writer_unittest.cc"
    }
  ]
}