Summary:
X-link: https://github.com/facebookincubator/velox/pull/7781
cxx.rs provides a more ergonomic and opinionated interop layer between Rust and C++ that we would like to leverage for future API chages.
This moves sapling_backingstore_get_tree_batch from the existing cbindgen implemenation to the new cxxbridge.
Reviewed By: MichaelCuevas
Differential Revision: D51645547
fbshipit-source-id: 0b11ea745efe02f282200fe5a325422978a1b466
Summary:
If you build Watchman from source on a machine without cargo, the
error message was confusing. You'd see "command not found" somewhere
mixed into ninja's output.
Change RustStaticLibrary, which is only used by Watchman and EdenFS,
to find cargo with find_program instead of guessing its name and
assuming it exists. This gives a much less confusing error message at
CMake configure time.
Reviewed By: genevievehelsel
Differential Revision: D40441374
fbshipit-source-id: eeafe615616775c660c700e14cf1f6b2fd9715a8
Summary:
We somehow have two different RustStaticLibrary.cmake in different places (one in eden repo and the other one in the shared opensource builder).
This diff merges them and switches Eden into using the shared CMake function (for the features option).
This diff also adds the features option for rust_executable funciton, which will be used in the next diff.
Reviewed By: kmancini
Differential Revision: D39038491
fbshipit-source-id: 99d61a1d5450010b345107a9ec5c761b62004aa6
Summary:
Pull Request resolved: https://github.com/facebookexperimental/eden/pull/110
Pull Request resolved: https://github.com/facebookexperimental/rust-shed/pull/27
Make it so that changes to rust-shed or other common rust source are used locally vendored, so they don't need to be pushed to github before they are visible in a build.
There was already some support for cargo vendoring in getdeps, but it was limited to dependencies between manifests built with cargo builder. This wasn't enough to build something like eden (cmake is main entry point, with later calls cargo) or eden_scm (make is main entry point, with later calls to cargo), so this diff adds a cargo prepare step for getdeps other primary build systems.
The cargo vendoring is done by using a cargo config file to point to the source files used by getdeps. It has two modes:
1. per crate, existing mode which is already automatic for cargo to cargo manifest dependencies. To use it for a non cargo build manifest, add crate.pathmap
2. per git url, existing mode which was only use for crates.io third-party crates, now can be enabled by setting cargo.cargo_config_file
Reviewed By: yancouto
Differential Revision: D33895469
fbshipit-source-id: 7b13c0b679532492a336ce217de875c25fe1be90
Summary:
Recently I found that its impossible to access elevated Watchman daemon from non-elevated process on Windows.
```
events.js:174
throw er; // Unhandled 'error' event
^
Error: connect EPERM \\.\pipe\watchman
at PipeConnectWrap.afterConnect [as oncomplete] (net.js:1106:14)
Emitted 'error' event at:
at Socket.<anonymous> (C:\open\ovrsource\unity\socialvr\_js\node_modules\fb-watchman\index.js:118:12)
at Socket.emit (events.js:198:13)
at emitErrorNT (internal/streams/destroy.js:91:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
at process._tickCallback (internal/process/next_tick.js:63:19)
```
To fix this, it was suggested by wez to use [his library](https://github.com/wez/EleDo) to force Watchman daemon always start in normal mode on Windows. In this stack of commits I did integrated his library into project and used it to force daemon restart in normal mode when spawned from elevated terminal.
To make it happen, I checked-in library sources and created proxy project which depends on the initial library and contains header bindings and cmake configuration. I did copy pasted Rust cmake macroses from another facebook project - eden, and also created analogue of autogen.sh but for Windows - autogen.cmd.
Pull Request resolved: https://github.com/facebook/watchman/pull/878
Test Plan:
Launch elevated terminal
Start watchman.exe produced from sources
Observe daemon starting and answering
In process monitor, observe watchman.exe process running under user group
Reviewed By: fanzeyi
Differential Revision: D25595879
Pulled By: arhelmus
fbshipit-source-id: 15eb29adcf5bd4a5708b6533a1b2bacbf13f431c
