Summary:
Our internal build infra creates a workspace and workspaces don't like
it when two crates have the same name. Eden scm had third-party rust crates that
were simple redirects to the internal location, but had the same name. This
caused breakages once these crates became part of the edenfs open source build.
Let's rename them to avoid this issue.
Reviewed By: kulshrax
Differential Revision: D23252539
fbshipit-source-id: 9ff2fa160a19c6bc54e015c71f9da7044ce659a7
Summary:
In order to do what the title says, this diff does:
1. Add the `eden/oss/.../third-party/rust/.../Cargo.toml` files. As mentioned in the previous diff, those are required by GitHub so that the third party dependencies that are local in fbsource are properly defined with a "git" dependency in order for Cargo to "link" crates properly.
2. Changes to `eden/scm/Makefile` to add build/install commands for getdeps to invoke. Those command knowing that they are called from withing getdeps context they link the dependencies brought by getdeps into their proper places that match their folder layout in fbsource. Those Makefile commands also pass a GETDEPS_BUILD env to the setup.py invocations so that it knows it is being called withing a getdeps build.
3. Changes to `eden/scm/setup.py` that add "thriftasset" that makes use of the getdeps.py provided "thrift" binary to build .py files out of thrift files.
4. Changes to `distutils_rust` to use the vendored crates dir provided by getdeps.
5. Changes to `getdeps/builder.py` and `getdeps/manifest.py` that enable more fine-grained configuratior of how Makefile builds are invoked.
6. Changes to `getdeps/buildopts.py` and `getdeps/manifest.py` to disable overriding PATH and pkgconfig env, so that "eden/scm" builds in getdeps using system libraries rather than getdeps-provided ones (NOTE: I've tried to use getdeps provided libraries, but the trickiest bit was that Rust links with Python, which is currently not providable by getdeps, so if you try to build everything the system provided Python libraries will collide with getdeps provided ones)
7. Added `opensource/fbcode_builder/manifests/eden_scm` for the getdeps build.
Reviewed By: quark-zju
Differential Revision: D22336485
fbshipit-source-id: 244d10c9e06ee83de61e97e62a1f2a2184d2312f
Summary:
Having fbsource's thrid-party crates in a separate folder will make it easier to provide a different manifest for the third-party crates for OSS builds.
In order to not trigger any network calls during internal FB builds you cannot define dependencies with "git" urls. Even if they are being patched up in the same manifest Cargo will still make a call to github. That is why internall the Cargo.toml files in third-party folder will contain dependency definitions that will use "path" dependencies only.
In the next diff a separate set of Cargo.toml files will be provided inside `fbcode/eden/oss` that ShipIt will replace for GitHub with the proper "git" url dependencies.
Note: Why even bother with "git" and "patch" section and not use only "path" dependencies? In OSS eden builds depending on other project - like fbthrift or rust-shed. They use regular "git" dependencies. So if you try to compile Eden that uses "path" dependencies with fbthrift/rust-shed that uses "git" dependencies you will get errors from Cargo saying that e.g. rust-shed's fbthrift_ext depends on "fbthrift" (from git), but the structure X implements trait Y from "fbthrift" (from path) which is not the same as trait Y from "fbthrift" (from git).
Reviewed By: quark-zju
Differential Revision: D22335430
fbshipit-source-id: 9b73f4f0bc09fa79b02488dc9b4640b97f90683c
