mirror of
https://github.com/facebook/sapling.git
synced 2024-10-11 01:07:15 +03:00
c763ab4b40
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 |
||
|---|---|---|
| .. | ||
| asyncrevisionstore/src | ||
| auth | ||
| backingstore | ||
| blackbox | ||
| bookmarkstore | ||
| cdatapack | ||
| clib | ||
| clidispatch | ||
| cliparser | ||
| commitcloudsubscriber | ||
| commitstore/bench-serialize | ||
| configparser | ||
| cpython-ext | ||
| dag | ||
| dev-logger | ||
| drawdag | ||
| dynamicconfig | ||
| edenapi | ||
| edenfs-client | ||
| encoding | ||
| fsinfo | ||
| hgcommands | ||
| hgtime | ||
| http_client | ||
| indexedlog | ||
| linelog | ||
| lz4-pyframe | ||
| manifest | ||
| manifest-tree | ||
| metalog | ||
| mincode | ||
| minibench | ||
| minibytes | ||
| mpatch | ||
| mpatch-sys | ||
| mutationstore | ||
| nodemap | ||
| pathmatcher | ||
| procinfo | ||
| radixbuf | ||
| renderdag | ||
| revisionstore | ||
| revlogindex | ||
| third-party | ||
| thrift-types | ||
| tracing-collector | ||
| treestate | ||
| types | ||
| util | ||
| version | ||
| vfs | ||
| vlqencoding | ||
| workingcopy | ||
| xdiff | ||
| xdiff-sys | ||
| zstdelta | ||
| zstore | ||
| CMakeLists.txt | ||
| README.md | ||
lib
Any native code (C/C++/Rust) that Mercurial (either core or extensions)
depends on should go here. Python code, or native code that depends on
Python code (e.g. #include <Python.h> or use cpython) is disallowed.
As we start to convert more of Mercurial into Rust, and write new paths entrirely in native code, we'll want to limit our dependency on Python, which is why this barrier exists.
See also hgext/extlib/README.md, mercurial/cext/README.mb.
How do I choose between lib and extlib (and cext)?
If your code is native and doesn't depend on Python (awesome!), it goes here.
Otherwise, put it in hgext/extlib (if it's only used by extensions) or
mercurial/cext (if it's used by extensions or core).