Summary:
A future diff will unify all config loading into configparser::hg, but
to do so we need dynamicconfig to live in configparser, so it can load
dynamicconfigs. Let's move everything in.
Reviewed By: quark-zju
Differential Revision: D22587237
fbshipit-source-id: 5613094175b6e1597aa113ee3e6d92ce7ec79f6d
Summary:
I think LZ4 was disabled accidentally in our rocksdb getdeps build in
D21319896. Enable it again on macOS and Linux, because otherwise this
breaks people with EdenFS mounts containing LZ4-compressed proxy
hashes.
Reviewed By: xavierd
Differential Revision: D21990356
fbshipit-source-id: b9166c2992ae51f09de3fa9a4f114143aa008f43
Summary:
CMake description of `JOB_POOL` is:
"A pool is a named integer property and defines the maximum number of
concurrent jobs which can be started by a rule assigned to the pool."
Not very clear by it looks like putting all the Rust jobs in it prevent CMake
from spawning concurrent jobs when these are running. This should help in
reducing the strain on the system while compiling, while not increasing
compile time.
Reviewed By: wez
Differential Revision: D21595135
fbshipit-source-id: e718c92a237274a9edbc35417644a46bdfde5617
Summary:
Previously, the Windows build was litered with warnings of the form (typo included):
warning C4250: 'C1': inherits 'C2::C2::method' via dominance
note: see declaration of 'C2::method'
Microsoft doesn't offer any recommendation, and the internet suggest that the
right `using` should silence it. That's unfortunately not the case, adding:
using C2::method
In `C1` doesn't do anything, and the compiler still complains :(.
Since the warning appears to be non-actionable, and looks more like a
"notice" than a warning, let's just silence it.
Reviewed By: wez
Differential Revision: D21395095
fbshipit-source-id: ae661b3ed61303e6361b8a15d9e7c6b9627ea8c1
Summary:
When using our vendored set of crates, cmake doesn't
have any dependency information to use to invalidate the Cargo.lock
file when we update crate versions. In addition, since we're
vendoring from a local directory, cargo itself doesn't seem to
want to re-assess the dependencies in that same situation, leading
to confusing error messages like this when we want to build rust
targets:
```
error: failed to select a version for the requirement `anyhow = "= 1.0.26"`
candidate versions found which didn't match: 1.0.28
```
This commit addresses this issue by removing the `Cargo.lock` that
may be alongside the `Cargo.toml` prior to invoking `cargo`.
`cargo` is pretty quick at recomputing the deps so this has
neglible overhead.
Reviewed By: xavierd
Differential Revision: D21394363
fbshipit-source-id: 547db2e2395a47aed77d9597e659eb2d96e274dd
Summary:
Previously we only included `basic_test.py` and `hg/status_test.py` in the
integration tests during CMake-based builds. This updates the code to now
include all of the test files, with just a few exclusions based on platform
type and what dependencies were available at build time.
Reviewed By: wez
Differential Revision: D21239912
fbshipit-source-id: b8826d249a6323ac3bcc555c9ceba54a4cbcfde9
Summary:
In the initial stages of the windows port we had
problems building rocksdb on windows, so we disabled it.
These days we're able to build it and detect it--we even
require it in the cmake code, but hadn't gotten around
to telling the rest of the code that we can use it.
This commit re-enables it in the build but leaves sqlite
as the default engine until we're able to perform some
benchmarking.
Rocksdb itself has some build issues on Windows; it doesn't
use cmake to locate dependencies, so even though we built
snappy it doesn't know how to find it without modifying the
source:
https://github.com/facebook/rocksdb/blob/master/thirdparty.inc#L4
For that reason, we disable the use of Snappy in the Windows build.
However, in the version of rocksdb that we were using, it would
default to trying to use Snappy even though it wasn't compiled in
and throw an exception.
I've upgraded to a newer version of rocksdb that will simply not
use compression if no compression was enabled at build time.
Given that we mostly store relatively small objects, I'm assuming
that the lack of compression is fine for now.
Reviewed By: xavierd
Differential Revision: D21319896
fbshipit-source-id: 2a2d06d4bd5382706e9220f9b4a2de99dc18311d
Summary:
This updates the top-level CMakeLists.txt file to compute package version
information, and expose this to C++ code in `eden-config.h`, and to Python
code in a new `eden/config.py` module.
Previously we exposed an `EDEN_VERSION` macro for the C++ code in
`eden-config.h`, but this was not initialized or used anywhere. Now the
top-level CMakeLists.txt file computes appropriate version information and
exposes the package name, version, release, commit ID, and build time in these
configuration files.
The version selection logic in CMakeLists.txt based largely on the code that
wez wrote for watchman in D20636833.
Reviewed By: wez
Differential Revision: D21000164
fbshipit-source-id: db1a1035f1eefec058bbad558d35e113005e454e
Summary: Actually use vendored Rust crates when building with CMake. The `--offline` option make sure cargo do not go to the Internet for missing crates.
Reviewed By: simpkins
Differential Revision: D20542672
fbshipit-source-id: ab4af40150c6af8b531a75f503a4fa848b3914da
Summary: All the crates are present in third-party/rust, let's use it in the OSS build instead of fetching a tarball of all the crates.
Reviewed By: fanzeyi
Differential Revision: D19770783
fbshipit-source-id: f0d74bb0807be207d599d4868f907d38099c7f5b
Summary:
We've had a small proportion of our users run into problems
with hdiutil and diskimages-helper, where those components get into
an unhappy state and effectively block operating on the redirections.
This diff introduces a new utility that is intended to replace the
use of disk image files with APFS volumes that we mount in the
appropriate places.
The intention is that we will teach `eden redirect` to use this tool
when available, rather than disk images.
macOS's security model is weird: it is perfectly valid for a non-privileged
user to create and delete APFS volumes in the APFS storage container,
but root privs are required to mount it into the VFS.
The intent is that we deploy this utility setuid root to minimize
the fan out--this way we won't need to teach the priv helper about
this kind of redirection.
There are a couple of subcommands demonstrated in the test plan.
Reviewed By: chadaustin
Differential Revision: D19323850
fbshipit-source-id: 35556f841e49e5c4b77679b756af9093222f4500
Summary:
The Rust vendored crates script also depends on another script and the
lfs-pointers file which specifies the ID to use for the download.
Update the RustStaticLibrary.cmake file to make sure that the vendored crates
are re-downloaded if either of these files change.
Reviewed By: wez
Differential Revision: D18846757
fbshipit-source-id: dd67d8d954a048501f0bdaddbd78147d39a1da5f
Summary:
Now that the fb-mercurial sources are available in the Eden repository, update
our CMake build files to always build them. This moves the build logic from
the centralized `FBMercurialFeatures.cmake` file into `CMakeLists.txt` files
in the appropriate subdirectories.
Reviewed By: chadaustin
Differential Revision: D18588011
fbshipit-source-id: ded9decde5c2ec766aae0bb0f4f5b021d1044a98
Summary:
Remove the standalone fb-mercurial-rust target that was an internal-only
dependency for the Eden build. This build step is now done entirely in the
Eden build.
Reviewed By: fanzeyi
Differential Revision: D18623943
fbshipit-source-id: c62a1155ddd1c0a6b2270c472176ba25194c6145
Summary:
Update the CMake build to always build the Rust datapack libraries, even on
Windows. This allows us to completely eliminate the `EDEN_HAVE_RUST_DATAPACK`
checks.
Note that I did leave the `EDEN_HAVE_RUST_DATAPACK` macro in place, as we
still do not build the Rust datapack code on Mac when building with Buck.
Reviewed By: fanzeyi
Differential Revision: D18588008
fbshipit-source-id: 1a4c9ceec5372d0e6a7313d2eb87edabd1e60a96
Summary:
Update Eden's top-level CMakeLists.txt file to build the Rust datapack
libraries. Previously these were built by invoking CMake separately inside th
`eden/scm` subdirectory. Now that the code has been combined into a single
location we can use a single CMake invocation to drive the build of both these
components.
The old code did not build the Rust datapack code on Windows, and this diff
does not change that behavior. I'm not aware of any reason to skip building
this on Windows, so I plan to enable building this code on Windows in a
subsequent diff.
Reviewed By: pkaush
Differential Revision: D18588006
fbshipit-source-id: 20f4f0ea9fef8595a9dd35a21115952b2808c824
Summary:
Add a CMake option to control whether or not we should build support for
fb-mercurial (aka Eden SCM). If this is disabled we avoid building anything
under eden/fs/store/hg and drop support for the "hg" backing store.
Reviewed By: wez
Differential Revision: D15980320
fbshipit-source-id: 23a49d3e5cf89199666ff4a0bf46626502c12171
Summary:
Add a CMake option to control whether or not we should build support for
Git. If this is disabled we avoid building anything under eden/fs/store/git
and drop support for the "git" backing store.
Reviewed By: wez
Differential Revision: D15980321
fbshipit-source-id: 434364d81b44935ce86fdf4d66697ee21ff2992f
Summary:
D17401218 updated the fbthrift CMake files to define components for the cpp2
and py generators. Eden requires both of these, so explicitly request them
when finding fbthrift.
Reviewed By: wez
Differential Revision: D17493950
fbshipit-source-id: 49410c08d847de404cc24c67fd1a25f75aad2518
Summary:
Update the getdeps manifest and Eden's CMake files to indicate that the
edenfsctl program depends on python-toml.
Reviewed By: chadaustin
Differential Revision: D17401215
fbshipit-source-id: f512678d8bca9c7b2b4d25bf9c3ecd7eed825de9
Summary:
The code in `EdenConfigChecks.cmake` had two separate `find_package(cpptoml)`
calls, one using its installed CMake config file, and one using a custom
`Findcpptoml.cmake` module.
This removes the custom `Findcpptoml.cmake` code, and updates everything to
only used cpptoml's installed CMake configuration.
Reviewed By: chadaustin
Differential Revision: D17401220
fbshipit-source-id: 3789703cdfc029049db3b1bd9f5751fa2a60a8d4
Summary:
This diff revises our cmake logic to search for the projectedfs
SDK in an additional location.
Reviewed By: strager
Differential Revision: D16907859
fbshipit-source-id: 0df26a675f09a327c01cb0bd1219e479ccd1dfe6
Summary: Using a positive meaning rather than a double negative makes the build a tad simpler.
Reviewed By: wez
Differential Revision: D17000782
fbshipit-source-id: ef6c7b64708aa9b1f50c7ad4086c492a90c944f4
Summary: Using a positive meaning rather than a double negative makes the build a tad simpler.
Reviewed By: strager
Differential Revision: D17000620
fbshipit-source-id: ff27eb8098786b8ed6ed1ba81166b51e29e62d47
Summary: Add a dependency from the eden open source build to the fb303 open source build and switch EdenServiceHandler to BaseService.
Reviewed By: simpkins
Differential Revision: D15528156
fbshipit-source-id: 2ca5c31dd9fcc9bac43fd399b27f33b6f2c5ebfc
Summary:
Don't print a status message about finding LZ4 twice: one is already printed
by `find_package_handle_standard_args()`.
Also change a few function calls to lower-case to be more consistent with the
rest of our CMake files.
Reviewed By: chadaustin
Differential Revision: D16435455
fbshipit-source-id: bc2c66399823162f93e62d1d0dbdba422fe63b24
Summary: We need --edenDir support to run muliple instance of Edenfs, which is required to run the integration tests.
Reviewed By: simpkins
Differential Revision: D15951483
fbshipit-source-id: a516159cdeb5f046f795fc28399a2af5fe8a9f95
Summary: Update the license headers in the remaining Eden files.
Reviewed By: wez
Differential Revision: D15487083
fbshipit-source-id: cea9cc133907eadf5afc069f5d420f686b4c1886
Summary:
Update the copyright & license headers in CMake files to reflect the
relicensing to GPLv2
Reviewed By: wez
Differential Revision: D15487079
fbshipit-source-id: 715e559464c19a0070d6e55a095b3fc7d61ad2f8
Summary: ThriftCppLibrary.cmake is a duplicate of the getdeps/opensource copy of the file. To avoid issues with keeping them in sync, remove Eden's.
Reviewed By: simpkins
Differential Revision: D15750453
fbshipit-source-id: 7f95d01c4ed6ce3af86f0215ef16b88dc2c61027
Summary: This is a stop gap solution to get the Windows build working with the getdeps, until we fix the SDK.
Reviewed By: chadaustin
Differential Revision: D15536740
fbshipit-source-id: 77cc6ea80c304a6cfcd0180bb28f63ce4dac2988
Summary: scm/hg/lib/clib/portability/mman.h needs EDEN_WIN macro defined to include the correct definition for Eden Windows.
Reviewed By: wez
Differential Revision: D15251101
fbshipit-source-id: 9ecf55f03aac2618398ed4c962d2e210e488b724
Summary:
beholdunittests
This enables some plumbing for running some of the
tests using the gtest/gmock machinery in cmake.
Part of this diff is removing the FindGMock.cmake file from the
eden repo; we now pull this in from the shared cmake library
that is populated by shipit.
Reviewed By: simpkins
Differential Revision: D14993344
fbshipit-source-id: 51caf9518c7f3a083a3b90cda10324c3a8170359
Summary:
In order to pull in the treemanifest and other libraries
from our mercurial repo, add a manifest file for it, and then
adjust the logic in our cmake module to look for it.
The fb-mercurial manifest just copies the source tree to the
installation dir. In the future, we could teach it to invoke
the build for real.
Reviewed By: simpkins
Differential Revision: D14969806
fbshipit-source-id: cb270c5003a1c134eeea92c7481a84938f1c5957
Summary: We intend to break support for flatmanifest hg, so require that treemanifest is available in the build.
Reviewed By: wez
Differential Revision: D15057150
fbshipit-source-id: 449399cfb9d018f3b722598091eead1bd5d7c77d
Summary:
Folly and thrift now require fmt, so we have to probe for it before
we probe for folly.
Reviewed By: chadaustin
Differential Revision: D15165394
fbshipit-source-id: 00d5f0cd5e9421ce0e3a4ea0de850deb4d4b5e3f
Summary:
- CMake allows the user to add additional compilation options using
`CXXFLAGS=<flags>` or `-DCMAKE_CXX_FLAGS=<flags>`.
- Eden clobbers these CMAKE_CXX_FLAGS for both debug and release modes
which prevents the user from passing additional flags.
- Teach Eden to respect user-supplied compiler flags instead of simply
overriding them.
Pull Request resolved: https://github.com/facebookexperimental/eden/pull/8
Reviewed By: simpkins
Differential Revision: D14481846
Pulled By: wez
fbshipit-source-id: 4d2034ddb4f9b781dde603a140c4d199eb0ad7d6
Summary:
`target_link_libraries` only allows passing things that
are libraries and expressly forbids passing in `-framework Foo`,
which is the sort of thing we get back from pkg-config on macos.
The result of misusing this is that cmake would add `["-framework", "-lFoo"]`
to the argv for the linker, which is totally broken.
Instead, we should use `target_link_options`.
Unfortunately, cmake seems to fail to do the right thing with the
` -framework CoreFoundation -framework Security` flags returned
from libgit2 on my system even using `target_link_options`; it somehow
ends up with a bare `Security` and fails to link. meh.
Reviewed By: strager
Differential Revision: D14680672
fbshipit-source-id: 62f65ddb4d07c8194cfc453cef1349b01be6c8b3
Summary:
While testing out the new getdeps code I found that none
of the include directories from the probed libraries were being used.
The new getdeps installs each dep into its own prefix, whereas the
existing getdeps script installed them into the installation
prefix for eden itself. That meant that they were being implicitly
found from a single include directory.
In addition to this, I encountered linker failures for the pretty
printers; the solution to those was to add appropriate deps for
the modules that depend upon the pretty printers.
Reviewed By: pkaush
Differential Revision: D14638758
fbshipit-source-id: a4c2b4c79603c268e1b1c707a05c3cb0e3f2757b
Summary: This diff add a MononokeBackingStore implemented based on libcurl so we could add Mononoke support on macOS.
Reviewed By: chadaustin
Differential Revision: D14096313
fbshipit-source-id: 2bcb0c49002dcbb0a0190ba505a6e814e74db747
Summary: Internal Facebook infrastructure is nagging me about some files not having a Facebook copyright notice. Add a notice to these files to make the nagging stop.
Reviewed By: simpkins
Differential Revision: D14173944
fbshipit-source-id: 7234431224fcf4f86ea56ca2f9108f47ef959d87
Summary:
This got lost partly because the symlink/shipit bit
was a manual step when I did this first time around, and partly
because the mercurial code got refactored.
Restoring treemanifest restores `hg up` performance to saner
levels.
This is fairly straightforward, but now that we have !wez building this we've
found that my machine had lz4 installed in the default include path and that we
need to probe and find the correct one, so that is part of this diff also.
Reviewed By: simpkins
Differential Revision: D14078886
fbshipit-source-id: 971cd49757bbb7dcc484439e6d896698598a583b
Summary:
Make `build-oss.sh` actually run the cmake build.
At the moment this is only run from nbtd for mac platforms,
so that is all that I've tested with it.
This is similar to the the equivalent scripts for watchman.
In a later diff we can centralize and clean up the duplication.
Reviewed By: simpkins
Differential Revision: D13910031
fbshipit-source-id: 6a7250c22033e913d999cf928fed27dada0647ef
Summary:
This requires our mercurial repo to be available during
the build; I symlink it in alongside `common` in the `oss` dir,
and point it up to `scm/hg`.
This has partial support for mononoke too, but will need to add
logic to getdeps to pull down the proxygen repo and build that.
Reviewed By: simpkins
Differential Revision: D13480146
fbshipit-source-id: 54874245015af83a259f56944d2e5f87615baee7
Summary:
There are some features of folly futures that are
currently being deprecated. Until that codemod lands, deprecation
warnings have been disabled in the buck build. To avoid
swamping the build output in the oss build, let's also turn
them off for cmake.
Reviewed By: strager
Differential Revision: D13686585
fbshipit-source-id: 14609a882bc78b7b31beb7ae02d762b9318e1312
Summary:
This is necessary because the folly installed cmake config
advertises that it requires glog::glog but doesn't specify how to
find it.
See also D13482288
Reviewed By: simpkins
Differential Revision: D13486767
fbshipit-source-id: 0713ae70a1863fc23a5e86c21e8f72e3ba9e4ed2
