Summary:
Github PR 423[0] changed the way that mvfst chose which headers to install. As part of this, certain directories, for example `/build/`, were filtered out.
Unfortunately this filtering is performed on the absolute path of the source code. If mvfst is cloned underneath any directory which matches one of the filtered directories, then all the header files will be filtered out and no headers installed.
Fix this by changing the initial list to be relative to the source directory such that the filtering cannot mistakenly match on paths outside the mvfst source tree.
[0] https://github.com/facebook/mvfst/pull/423
Pull Request resolved: https://github.com/facebook/mvfst/pull/427
Reviewed By: jbeshay
Differential Revision: D95509252
Pulled By: afrind
fbshipit-source-id: 0dbeb0ece5527c60a2bff82a8ff322744f9675a0
Summary:
Pull Request resolved: https://github.com/facebook/mvfst/pull/423
Similar to the folly, fizz, and wangle granular CMake implementations, this adds
granular library targets for mvfst that work with both static and shared library
builds.
Key changes:
- Added MvfstFunctions.cmake with mvfst_add_library() function
- Creates OBJECT libraries for compile-once, use-many pattern
- Creates STATIC libraries (static builds) or INTERFACE libraries linking
to monolithic mvfst (shared builds)
- Added generate_cmake.py to auto-generate CMakeLists.txt from BUCK files
- Added lint_cmake_sync.py for arc lint integration
- Added MvfstCompatAliases.cmake for backwards compatibility with old target
names used by downstream projects (proxygen, moxygen, thrift)
Backwards compatibility aliases properly include all transitive dependencies
that the old targets had (e.g., mvfst_server now includes qlogger and fizz
server handshake).
Reviewed By: lnicco, kvtsoy
Differential Revision: D91009061
fbshipit-source-id: f745e05fcf74a6d6b0c9343731e7772bc342ccc9
Summary:
These libraries were removed in fc66b07859.
The corresponding targets should be removed from the CMake config or
else doing `find_package(mvfst)` in CMake will fail due to the missing
libraries.
Pull Request resolved: https://github.com/facebook/mvfst/pull/416
Reviewed By: jbeshay
Differential Revision: D89327030
Pulled By: kvtsoy
fbshipit-source-id: 1c9e6d29a0ed61ce0f5fe038339653c7f4c4d0a1
Summary: See title. Currently, all use cases use `quic::follyutils::decodeQuicInteger`, but we're gradually going to migrate mvfst to use `quic::decodeQuicInteger`.
Reviewed By: kvtsoy
Differential Revision: D80472391
fbshipit-source-id: 3b5e893706503652b0eccee0d4c4558e216e3242
Summary:
The long-term plan is to migrate all the usages of `folly::io::Cursor` within the mvfst library to the `ContiguousReadCursor`. In order to do that, we're going to follow the following sequence:
1. Migrate mvfst to use `quic::follyutils::decodeQuicInteger`.
2. Change the implementation of the existing `decodeQuicInteger` within QuicInteger.h to use the `ContiguousReadCursor`.
3. Slowly initiate the migration of current use cases of `folly::io::Cursor` to the `ContiguousReadCursor`.
Reviewed By: mjoras
Differential Revision: D80374103
fbshipit-source-id: ee1585ba7cb881bd3f8ec178543d7b8de57532b9
Summary: The logic for deciding which ACK type to write was duplicated in QuicPacketScheduler and QuicPacketRebuilder. This refactors the logic out into a separate QuicAckScheduler so it can be tested for correction and reused in both places.
Reviewed By: sharmafb
Differential Revision: D69933311
fbshipit-source-id: e4f45688a5d258dd2a57f9f7844407f3efad5f49
Summary:
Rather than having a separate copy of applySocketOptions inside QuicServerWorker to work on FollyAsyncUDPSocketAlias (folly::AsyncUDPSocket), this templatizes the SocketUtil function so it can be used with both types and avoid duplication of the socket option filtering logic.
Since the header file only had one other one-line function, I moved that function into the header file as well and removed the SocketUtil.cpp file.
Reviewed By: mjoras, frankfeir
Differential Revision: D52182467
fbshipit-source-id: 7c8aff164edafb12b26746f766ac6e5fc20c88d5
Summary: currently it is not part of the build
Reviewed By: hanidamlaj
Differential Revision: D46703017
fbshipit-source-id: 599f24d851b1322cdc93942466fb7769df0be5b8
Summary:
Define the `mvfst_LIBRARIES` variable in `mvfst-config.cmake.in`. This will define the variable when `mvfst` is found using the CMake `find_package` function. The `mvfst_LIBRARIES` variable definition is composed of references to the libraries compiled by the `mvfst` CMake project.
Also correct a typo implying that proxygen library is built by the mvfst project.
Reviewed By: kvtsoy
Differential Revision: D39552920
fbshipit-source-id: 7af1c4c4561a9952c702eb8c1ec6d8eb827a8e1c
Summary: properly find the required GMock version (1.8.0) and allow building tests in getdeps
Reviewed By: mjoras
Differential Revision: D16935741
fbshipit-source-id: 46f62511e2feaf553d028e286a862aa5b30393c6
Summary: Remove the shared CheckAtomic cmake module out of the shared dir and back to the projects that need it.
Reviewed By: lukaspiatkowski
Differential Revision: D19553656
fbshipit-source-id: 5e89b5b9448ef6d6c57ef904a652e9f9a1d5dbb3
Summary:
When building with clang, the build fails with:
```
-- Looking for __atomic_is_lock_free in atomic
-- Looking for __atomic_is_lock_free in atomic - not found
CMake Error at cmake/CheckAtomic.cmake:90 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
CMakeLists.txt:75 (include)
```
And the error is:
```
/usr/share/cmake-3.10/Modules/CheckFunctionExists.c:7:3: error: conflicting types for '__atomic_is_lock_free'
CHECK_FUNCTION_EXISTS(void);
^
<command line>:1:31: note: expanded from here
#define CHECK_FUNCTION_EXISTS __atomic_is_lock_free
^
/usr/share/cmake-3.10/Modules/CheckFunctionExists.c:7:3: note: '__atomic_is_lock_free' is a builtin with type 'int (unsigned long, const volatile void *)'
<command line>:1:31: note: expanded from here
#define CHECK_FUNCTION_EXISTS __atomic_is_lock_free
^
/usr/share/cmake-3.10/Modules/CheckFunctionExists.c:17:25: error: too few arguments to function call, expected 2, have 0
CHECK_FUNCTION_EXISTS();
~~~~~~~~~~~~~~~~~~~~~ ^
```
LLVM's CheckAtomic (https://fburl.com/bk14shjt) uses `__atomic_fetch_add_4` so I'm modifying the configs to use it as well to check for the existence of the library.
Reviewed By: yfeldblum
Differential Revision: D19497168
fbshipit-source-id: 64f77487efd16dba49055f6c4cb1cdd0fc4ae6da
Summary:
* Remove some old kruft and what looks like an old debugging message from `CMakeLists.txt`
* Only use `-Werror=bool-compare` if the compiler actually supports it
* Mark a bunch of C++ method parameters as `FOLLY_MAYBE_UNUSED` to avoid compiler warnings
* Fix a bunch of signed/unsigned comparisons in tests to avoid compiler warnings
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/9
Reviewed By: yangchi
Differential Revision: D15281424
Pulled By: mjoras
fbshipit-source-id: 0d6dc6d30a93032e9ee2e9b7d0873b4a2ecd7650
Summary: This is no longer necessary now
Reviewed By: yangchi
Differential Revision: D15930219
fbshipit-source-id: d277190811c5f5f507783aeddbd8cedb1284e59a
Summary:
After changing fizz to export test headers and lib, we do not need to pull in
fizz as an ExternalProject anymore. This simplifies and fixes a lot of build
issues
Reviewed By: yangchi
Differential Revision: D15930220
fbshipit-source-id: dcb01c46b8ade545047c20af2fc5245223afff99
Summary:
When consuming fizz as an external target, it's wasteful to build test targets
of fizz.
This should fix the travis build timeout of mvfst in oss:
https://travis-ci.com/facebookincubator/mvfst/builds/114688200
Reviewed By: yangchi
Differential Revision: D15712260
fbshipit-source-id: 2c7c1262bb40962c169f5f922e1343e9ab27410e
Summary:
If you specify the `LOG_*` directives, then nothing appears on stdout
while the external project is building. On my Mac, this means it sits
at the Fizz build step for 4+ minutes with no visible progress in the
terminal.
Removing the `LOG_*` directives means that cmake will display all the
output to stdout instead of to files. This is consistent with the
build behavior for Folly (which is not a cmake ExternalProject). If
logging the external project builds is desired, the user can capture
the output of the build_helper.sh.
Signed-off-by: Jeff Squyres <jeff@squyres.com>
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/8
Reviewed By: lnicco
Differential Revision: D15267875
Pulled By: udippant
fbshipit-source-id: 138c0f1af6679d2c6e5bbb243d7891211763820c
Summary:
This adds path of newly built dependencies so that 'external-projects' such as
fizz can find them
Reviewed By: lnicco
Differential Revision: D15253200
fbshipit-source-id: 993bb030e3a3800697215af089e24482b664d782
Summary:
Relying on the default find for gtest / gmock (via LIBGMOCK_FOUND) is set to
true if another version of gmock is already installed and can be incompatible
Reviewed By: siyengar
Differential Revision: D15216828
fbshipit-source-id: 94d6e1a14914181842e34bd262b1a46c59155435
Summary: Do not rely on downloading it via wget in `build_helper.sh`
Reviewed By: siyengar
Differential Revision: D15215226
fbshipit-source-id: aeef31b30964674d80346aa6a1480ce03fdf478d
