Summary:
Since FilteredFS uses an entirely separate `eden clone` command, none of the existing Hg tests run using a FilteredBackingStore-backed repo. To ensure we have proper test coverage for FilteredFS, we should add a FilteredFS mixin type that runs all existing tests with the new FilteredBackingStore setup.
Introducing these mixins revealed a number of broken tests (some legit issues with FilteredFS, others are just incompatibilities with new FilteredBackingStore Root/Object Ids). We will disable all of these broken tests and incrementally fix them in the next diffs in this stack.
Note: A small number of tests are already broken/flakey for non-FilteredFS tests. They are "ignored" on other diff signals since they are marked flakey/broken in TestX, but the FilteredHg counterpart won't be marked accordingly (due to no run history). I'm not planning to fix those existing flakey/broken tests just yet.
Reviewed By: kmancini
Differential Revision: D51287692
fbshipit-source-id: 8135cb9e5e9dba08be48a4814dfc3405122127b8
Summary:
I ended up in a crazy situation where the CMake build was failing to
link because `target_link_libraries` had a cycle. Fix that by
preventing cycles in the first place. CMake is the gift that keeps on
giving.
Reviewed By: xavierd
Differential Revision: D45927359
fbshipit-source-id: 6a378f7935195e42b3446249091898370d6e2ee5
Summary:
With Facebook having been renamed Meta Platforms, we need to change the license
headers.
Reviewed By: fanzeyi
Differential Revision: D33407812
fbshipit-source-id: b11bfbbf13a48873f0cea75f212cc7b07a68fb2e
Summary:
Currently we have limited test coverage of the NFS code. Let's start running
our integration tests on NFS mounts. We already duplicate tests to run them on
both Git and Hg repos using a python decorator. We can update this decorator to
run a copy of tests on an nfs mount.
This covers most of the tests, but a few tests do not use this decorator. See next
change.
Note some tests are currently broken, so I am using the same skip list functionality
we use for windows so we use a uniform framework.
Reviewed By: xavierd
Differential Revision: D27874662
fbshipit-source-id: c7d425830b691e395b5228d0e0f797f67987b4ec
Summary:
On macOS, the compiler shows tons of warnings due to our use of pointers where
nullability attributes aren't set, and the compiler complains about it. This
makes finding legitimate warnings/errors almost impossible, thus for now let's
disable these.
Reviewed By: fanzeyi
Differential Revision: D27862116
fbshipit-source-id: 8ea2c27a0cfd6cbd484fca6be5f15c772d9f4589
Summary:
The code still took a dependency on Mercurial's old manifest code to parse
manifests. It turns out the manifests have a very simple format that we could
parse directly.
This avoids various copies, conversions, std::list, removes ~1k lines of code,
at the expense of adding ~100 lines of code (some of them being C++
boilerplate).
Reviewed By: fanzeyi
Differential Revision: D25385018
fbshipit-source-id: 90d4cda2b7797584bc48c086d5592a7ecaa05dfc
Summary: The code doesn't use anything from libmpatch, we don't need to depend on it.
Reviewed By: DurhamG
Differential Revision: D24055084
fbshipit-source-id: 0f7bac73f1b711da4395e25619577a0a2e0ca959
Summary:
In order to start EdenFS automatically at boot, a template service was used
previously, but due to several issues, we decided to move away from it.
Thankfully microsoft supports several other ways of starting tasks at startup,
one of which is the "Task Scheduler" itself.
One of the weird part of the task scheduler is that there isn't a good way
to tell it to not show a console for a non-graphical application, and thus
plainly executing edenfsctl start in it would create a cmd window, which
would then disappear a couple of seconds later. To avoid this, a "graphical"
version of Python is used (pythonw.exe) to start edenfsctl.
Reviewed By: fanzeyi
Differential Revision: D21732281
fbshipit-source-id: 87ef3a2d5569302392bd30a4b9e7fc48807ee316
Summary:
This script deals with obtaining the right privilege to start the EdenFS
service. This effectively enables `edenfsctl start`.
Reviewed By: wez
Differential Revision: D21585739
fbshipit-source-id: 7b835434d865fa4c4c8473e13665ae669fd86108
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:
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:
Update the CMake build to emit a LIBRARY_DEP_DIRS.txt file in the build output
directory. This file should contain additional directories that may contain
runtime library dependencies for the generated build artifacts, one directory
per line. This file will be parsed by getdeps.py so that it can set `$PATH`
properly when running tests in order to find all of the necessary library
dependencies.
At the moment the runtime location of the Python DLL is the main thing that
needs to be stored in this directory. CMake can find the Python location from the
registry, even if that location is not in the user's `$PATH`. On its own
getdeps.py won't be able to find the location of the Python DLL unless we
explicitly give it this information through this file.
Reviewed By: wez
Differential Revision: D20688289
fbshipit-source-id: 078d07d860de8604c97bf6adede464c0d95fc079
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:
Add an option to CMakeLists.txt so that when building on Windows the Python
DLL will also be installed into Eden's `bin/` directory. On Windows our
Python-based tools are compiled into `.exe` files that require this DLL.
Installing the Python DLL along side our binaries is an easy way to ensure
that these executables can always find the correct library.
It would perhaps be nicer if we could simply link against Python statically.
Unfortunately the `FindPython3.cmake` file that ships with CMake silently
ignores requests to link statically on Windows. (They provide a
`Python3_USE_STATIC_LIBS` option, but it is explicitly ignored on Windows.)
In the long run it might be nicer to attempt to fix that.
Reviewed By: pkaush
Differential Revision: D19060632
fbshipit-source-id: 6995fe6b81b820cf8e0713687751c1a811e97f88
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 initial support for building and running some of the integration tests
with CMake. For now this just runs the tests from basic_test.py, just to
confirm that most of the framework code works in CMake-based builds.
Many of the other tests should also work as well, but a few of them we may
want to disable for CMake-based builds. e.g., a couple of the tests depend on
hypothesis, and we would need to include hypothesis as a dependency. Some of
the tests that use systemd might also require a little more work to get
working.
Reviewed By: fanzeyi
Differential Revision: D17659026
fbshipit-source-id: 67420fda9e1021a0cddee2d385fd21e34fb2fd70
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:
The `add_fbthrift_library()` functions require CMake 3.8+ for the
`COMMAND_EXPAND_LISTS` support in `add_custom_command()`
Reviewed By: fanzeyi
Differential Revision: D17512088
fbshipit-source-id: 1b60976f3097b11d0ad2912ee8068f40520dd9c1
Summary:
Update the CMakeLists.txt to also build the Python-based `edenfsctl` command
line tool.
This requires switching most of the thrift rules to generate both C++ and
Python sources.
Note that one missing feature at this point is that this does not package
external dependencies into the binary. Currently `edenfsctl` depends on both
`six` and `toml` as external dependencies. For now these must be available in
your `PYTHONPATH` in order to run the generated `edenfsctl` binary.
Reviewed By: chadaustin
Differential Revision: D17127615
fbshipit-source-id: fc138ab39e75c6a5bbd39e3f527d4e9f7f420e46
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: 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:
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: CompilerSettingsUnix adds /Wextra and other compiler flags which will error when building with Visual studio.
Reviewed By: chadaustin
Differential Revision: D15536742
fbshipit-source-id: af842f6ad50833f29fbfb602cdf793d0c4de11a9
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:
the new getdeps script places the osxfuse/common dir into
its own install prefix, rather than dropping them into `external/osxfuse`.
This configures cmake to check in the installation prefixes known
to cmake.
Reviewed By: strager
Differential Revision: D14683956
fbshipit-source-id: 6e8a73341f8ddc21fef4b40b1f18a4a5128810e3
Summary: This diff fixes Folly's xlog when building with CMake.
Reviewed By: strager
Differential Revision: D14155982
fbshipit-source-id: cb88500ca1fa9f5f748129e1d11471cecd71ce22
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's nothing nice about this; the full set of kernel headers are
not installed with the binary distribution, and since the kernel distribution
has to be signed to be loaded on osx, there's no benefit to us building it
for ourselves.
This diff adds a nop builder and tweaks the cmake to point into the osxfuse
repo.
The osxfuse repo aggregates a couple of related repos using the git
submodule feature, so trigger that from getdeps.py too.
Reviewed By: strager
Differential Revision: D13480148
fbshipit-source-id: 84e09a86f6a83f83ffd1e3fe113dc7b15b3ea208
Summary:
Tell the compiler that we want to enable C++17 features.
This is required in order to use `std::is_default_constructible_v`, and it
prevents the compiler from warning about structured binding declarations.
Reviewed By: chadaustin, strager
Differential Revision: D10503904
fbshipit-source-id: 8fc521abdb261c787eabb3908bf7d4c2c8e46f2b
Summary:
I tried to build eden using GitHub version and ran into SELinux issues.
This patch fixed related issues, namely:
- `set(X Y)` sets X to string literal Y. Change it to `set(X ${Y})`.
- `SELINUX_INCLUDE_DIR` could be undefined. Check before use it.
- `./eden/fs/eden-config.h` and `./build/eden/fs/eden-config.h` both exist and
the former is used. Set include dirs so the latter gets used.
Reviewed By: bolinfest
Differential Revision: D9029272
fbshipit-source-id: 0c94bbe2f9e3fa90973802ddde16ad4d9ddfc0e8
