Summary:
This fixes a few issues with the library dependencies:
- The `eden_utils` library depends on `eden_service_thrift`, not
`eden_service`. By incorrectly depending on `eden_service` this introduced
a circular dependency which would cause a build failure, depending on which
order CMake chose to try and emit the link line.
- The `eden_config` library depends on code from `eden_model` (for `Hash` and
`ParentCommits`)
- The `eden_inodes` library depends on `eden_model_git` for the `GitIgnore`
logic. I also alphabetized the dependency list.
Reviewed By: wez
Differential Revision: D17124930
fbshipit-source-id: 70cbe81081fc1dc807cca13a93edc25ba270b01f
Summary:
This module provides a `add_fbthrift_library()` convenience function that can
be used to generate thrift libraries for multiple languages with a single
call.
Reviewed By: wez
Differential Revision: D16742275
fbshipit-source-id: c13120cf9e051629951282141eb22f3e085782f9
Summary:
This module helps generate Python libraries from thrift files.
It is the Python equivalent of `FBThriftCppLibrary.cmake`
Reviewed By: wez
Differential Revision: D16742274
fbshipit-source-id: ef0dc7f24eb1c7375d2587ee6b71fd25bd6f35a7
Summary:
Fix a minor bug in the argument parsing for `add_fbthrift_cpp_library()`:
only a single value should be supplied for the `THRIFT_INCLUDE_DIR` argument.
This parameter should not accept a list of arguments.
Reviewed By: strager
Differential Revision: D17125810
fbshipit-source-id: 31f354e4d6299d3626a94f3b4b5ff8c58bb0cf7b
Summary:
Rename the `ThriftCppLibrary.cmake` file to `FBThriftCppLibrary.cmake`, and
also rename `add_thrift_cpp2_library()` to `add_fbthrift_cpp_library()`.
Explicitly calling this `fbthrift` helps clearly distinguish that this is
intended for use with fbthrift (https://github.com/facebook/fbthrift/), as
opposed to Apache thrift.
Reviewed By: wez
Differential Revision: D16738440
fbshipit-source-id: 9b255e06b71c98ad74a34989f564a211958dcdd5
Summary:
Implement the repair() logic for InodeDataError, MissingMaterializedInode, and
OrphanInode.
The most common errors we see after an unclean system reboot is an inode file
not being present at all (`MissingMaterializedInode`), or it being present but
empty (`InodeDataError`). When either of these errors occurs for a directory
it also produces `OrphanInode` errors, as all of the children entries in the
directory are no longer part of the directory hierarchy.
This implements repair logic for these three error types. The repair behavior
is largely similar to the Python version in `eden/cli/fsck.py`, with some
minor changes to the output paths in the `lost+found/` repair directory. This
also includes more unit test to better exercise handling when `InodeDataError`
and `MissingMaterializedInode` errors occur inside an orphan subdirectory that
needs to be extracted to `lost+found`
Reviewed By: strager
Differential Revision: D16577696
fbshipit-source-id: 948158c5a0c32b31574d93011281c42051645ad9
Summary:
I added a None check to make redirect fixup work on macos
where we don't return running build information, but this broke the
integration tests (which don't run on mac!) where the build information
is actually the empty string.
Only check the version date if it is truthy, otherwise it will always
evaluate as less than the cutoff date and short-circuit the fixup
command.
Reviewed By: fanzeyi
Differential Revision: D17113336
fbshipit-source-id: 38dff9157a760b747958722e70567871dccd8cc0
Summary:
Update install_fb_python_library() to work with CMake versions older than 3.7.
Previously the code used a generator expression in the directory argument
supplied to `install(DIRECTORY)`. Support for generators in this parameter
was only added in CMake 3.5, but it was buggy and did not correctly handle
absolute paths until 3.7.
This updates the code to avoid using a generator expression. This does
require that the corresponding `add_fb_python_library()` statement appear
before the `install_fb_python_library()` statement, but this seems like a
pretty reasonable restriction.
Reviewed By: chadaustin
Differential Revision: D17103597
fbshipit-source-id: 54d6af93a3f530373cfe3137db99436d8484f308
Summary:
If the hg_import_helper (really `hg debugedenimporthelper`) command
claims to not support treemanifest, then immediately fail.
Reviewed By: strager
Differential Revision: D15302513
fbshipit-source-id: 044a9cba877d65b6dab0ede6b431146a361d2801
Summary:
The 2018-11 and 2019-03 snapshots were created with flatmanifest
repositories. Flatmanifest support is going away, so update them with
treemanifest repositories.
I untarred them and added an hgrc containing the following contents:
```
[extensions]
treemanifest =
[treemanifest]
treeonly = True
[remotefilelog]
reponame = snapshot
```
It's a bit janky to update a repo in place like this, but it means the
snapshot doesn't have to be recreated from scratch.
Reviewed By: simpkins
Differential Revision: D17103193
fbshipit-source-id: 62da8c2fe579d90281af83d4d8912cc64b09897b
Summary: Create config.toml in first Eden start up and store initial local store flag.
Reviewed By: chadaustin
Differential Revision: D16993074
fbshipit-source-id: dca8dbe60a892b7402ebf2f6c17df715dd2e8792
Summary:
The snapshot generation code and many integration tests create
repositories. By default, they were creating flatmanifest
repositories, which are on their way out. Instead, create tree-only
repos.
Reviewed By: strager
Differential Revision: D17066151
fbshipit-source-id: f99a9543440da6fd7cce0065c3cd7f91a59a02d5
Summary:
We saw some weird cases where we'd get error spew when
folks were using `eden redirect fixup` against really old servers,
despite us having fallback logic for those.
For now let's do a simple manual pre-check; we use july first as
the min server version for this; it was technically available earlier
than that, but this seems like a safe date to use in case of delays
in pushing out that code.
Reviewed By: strager
Differential Revision: D17094330
fbshipit-source-id: 239378906d382cb249a74e1534d0cd363988eaed
Summary:
Update the generated `run_cmake.py` script to use `os.execve()` rather than
`subprocess.call()`, so that it now propagates CMake's return code back to its
caller.
Reviewed By: chadaustin
Differential Revision: D17089206
fbshipit-source-id: e01f05f492ccb842d4967e59fd0bc9a3e59b8a42
Summary:
Fix printing the manifest context in the error message if we cannot find a
project fetcher. Previously the context in the message would be printed as
something like `<getdeps.manifest.ManifestContext object at 0x7fcce987e610>`,
now it shows instead as something like
`{distro=ubuntu, distro_vers=18.04, fb=off, os=linux, test=off}`
Reviewed By: chadaustin
Differential Revision: D17089208
fbshipit-source-id: c16549b61030d813b7b5ff9f65966436dc1e1898
Summary:
This just strips off a trailing '/' from the `INSTALL_DIR` property that we
set on python targets, to avoid having double-slashes in the paths that we use
during installation. This shouldn't really have any material difference other
than cleaning up the paths that get printed during the installation phase.
Reviewed By: chadaustin
Differential Revision: D17089207
fbshipit-source-id: ab36bb76c19fa60fe037f7a5290ccfd6bdbf13b0
Summary:
Update fboss to use `ThriftCppLibrary.cmake` directly from fbcode_builder
rather than maintaining its own copy of this file.
Reviewed By: chadaustin
Differential Revision: D17005421
fbshipit-source-id: a64df426118df6088b47f09410dad7b8b7e79a43
Summary:
Update `add_thrift_cpp2_library()` to pass in the correct `-I` flags when
invoking the thrift compiler so that it can find all of the other thrift files
that this library depends on.
D16062657 was a previous attempt to do this, but suffered from a few problems:
- It required all dependencies to be defined before
`add_thrift_cpp2_library()` was called. This requires users to carefully
order their CMake files and subdirectory include ordering.
- It only handled one level of dependencies, and did not propagate include
paths for deeper dependencies.
- It set the include path for dependencies to the source directory path where
the dependency was originally built, rather than the directory where the
thrift file for that dependency would be installed.
This change does require CMake 3.8+. Previous versions of CMake do not
support using generator expressions to generate multiple arguments for a
custom command.
Reviewed By: strager
Differential Revision: D17005381
fbshipit-source-id: 31190beba94b4d1010445375a5e2791450230f7d
Summary:
This diff adds a fuse request timeout configuration setting
and threads it through to both the FuseChannel for our internal processing
and to the privhelper so that we can set an appropriate (slightly larger)
value for the kernel level daemon_timeout setting.
Reviewed By: chadaustin
Differential Revision: D16957552
fbshipit-source-id: a0fecc691d72914b5aebaed8a006dc0d6b0d7d12
Summary:
The macOS FUSE implementation has the concept of a daemon timeout,
which is used to set an upper bound on the length of time that the kernel will
wait for a request to be satisfied. If a request takes too long, the kernel
will shutdown the fuse device and the user is left with a relatively broken
experience in their repo until they restart the eden server. Critically, when
it is left in the broken state it is hard for the user to realize that they
need to restart the server because the kernel will still respond with EIO to
file accesses within the mount; even though it has been stopped, it isn't
fully unmounted until the fuse process stops.
This diff introduces a self imposed timeout in the fuse processing flow
and emits an ETIMEDOUT error when it is reached.
The intent is that we'll configure this timeout to be smaller than the
macOS daemon_timeout (which will be adjusted in a separate diff) so
that we don't trigger the problematic behavior when the kernel decides
that we've timedout.
This change is made for all fuse implementations, not just macOS, for
the sake of consistency: there's value to doing this on Linux as well,
to avoid some deadlock like scenarios: this should put an upper bound
on blocking in certain situations.
I've made the timeout default to 60 seconds, but haven't added any
configuration code for this yet; will do that in a follow on diff.
Reviewed By: chadaustin
Differential Revision: D16917954
fbshipit-source-id: 675539c43cf7f0009fd65d138081b9126464b7e0
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:
on linux kernel 5.1 we noticed that some caps were requested but not
known to the diagnostic code. This little diff adds a missing entry.
There is still one more that is unknown, but I think that we'll need to update
our copy of the fuse header to get that handled here.
Reviewed By: chadaustin
Differential Revision: D16953397
fbshipit-source-id: 30d19843a2cf1ec22fd469654773afaafa8e3b9b
Summary:
We are now using the open source fb303 stats libraries so
these locally managed headers are no longer needed.
Reviewed By: chadaustin
Differential Revision: D16969961
fbshipit-source-id: 71df4add75b045967a0087721c0b742edcabdf4d
Summary:
All of the requisite headers are now open sourced and eden
has been converted to use them. This removes any logic that references
this directory and kills the now unused cmake file.
Reviewed By: chadaustin
Differential Revision: D16994732
fbshipit-source-id: 573b8b50540ee64590682be2a54aa94659f12368
Summary:
Most stat code in fbcode was moved in to open source under
fbcode/fb303. The only exception that we use internally is the
MonotonicCounter class. This diff moves all of our stats code to use
the open source headers and updates cmake files to pull in the open
source fb303.
Reviewed By: chadaustin, shri-khare
Differential Revision: D16969960
fbshipit-source-id: 12b7abb54c956c242c8e27eb69fd96925c7e61f7
Summary:
StartingGate was similar to std::barrier except that it guaranteed the
coordinating thread woke the worker threads. While this symmetry is
nice in concept, given enough threads, I doubt it pays for the
duplication.
Just adopt folly::test::Barrier (which is basically std::barrier)
instead.
Reviewed By: strager
Differential Revision: D16942136
fbshipit-source-id: 1691d8ef72b88c8867df74c8ed938f6c8d6ee094
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