Summary: This enable test targets to be built and ran
Reviewed By: lnicco
Differential Revision: D17408942
fbshipit-source-id: 144d223bc3830d07a0420e9569d3166a8646cd9a
Summary: changes the way it pulls its dependencies
Reviewed By: wez
Differential Revision: D17363235
fbshipit-source-id: 37e509c7e413f763e3553e9f01ac23951045089c
Summary:
Update the thrift C++ and Python CMake rules to indicate that the output also
depends on the thrift compiler itself.
Previously the C++ rule indicated that the output depended on the thrift
template files, which caught most cases when the thrift compiler was updated,
but wasn't fully correct. The thrift templates were also removed and baked
into the thrift compiler binary in D16356056.
Reviewed By: yfeldblum, chadaustin
Differential Revision: D17401217
fbshipit-source-id: ae5cde7a7e5e07a74406a1b6f4469124187bc12f
Summary:
This is useful when working on changes to some of the builder functions,
to skip ever trying to use cached results.
Reviewed By: chadaustin
Differential Revision: D17401219
fbshipit-source-id: fb7d5ea45618653957b9bd6a62eed91d8334824d
Summary:
This commit teaches fixup-dyn-deps how to generate correct
absolute paths in the context of the ultimate install path (specified
via the `--final-install-prefix` option)
Absolute paths are desirable if you have, for example, an executable
that you wish to install with the setuid bit set.
Reviewed By: simpkins
Differential Revision: D17361491
fbshipit-source-id: 4c4f3f15208266300622f84dc9cd1ba83883dfb7
Summary:
Add a license header to satisfy the open source linter. Use the same
header the other .cmake files have.
Reviewed By: mhlakhani
Differential Revision: D17404782
fbshipit-source-id: 66679d72c9e680f8bb8b27869e981a046b3520cf
Summary:
This commit adds a getdeps command that is able to generate
a workflow file for the GitHub Actions CI environment.
The workflow file could be expressed more simply using the matrix
syntax and with three steps (checkout, build, test), but I chose to
break out the steps for each of the dependencies because the UX
while waiting on the build is much nicer that way: the steps show
during and live log tailing for the section of the build that is
underway. If they were all lumped into a single build step then
the logs from the boost section of the build dominate and make
the github UI work very hard.
Pull Request resolved: https://github.com/facebook/watchman/pull/743
Test Plan:
https://github.com/facebook/watchman/pull/743 successfully
executes the github actions CI flow.
```
$ opensource/fbcode_builder/getdeps.py generate-github-actions --output-file watchman/.github/workflows/main.yml watchman
```
Reviewed By: simpkins
Differential Revision: D17384915
Pulled By: wez
fbshipit-source-id: 9a9e5a3e806c18f6cc38ba1cb7059740cda01ad4
Summary:
GitHub Actions CI `windows-latest` environment has only VS 2019
installed, so we need to expand our logic to be able to locate it.
Note that Boost 1.69 doesn't know how to locate VS 2019 so we are effectively
tied to VS 2017 at the moment; the search order in this diff reflects that.
(That means that we can't target `windows-latest` on GitHub Actions, but that
is really a concern for a later diff in this stack)
Reviewed By: simpkins
Differential Revision: D17385052
fbshipit-source-id: 9bb0612154f42d425a625406488f39bb4ec3d8ae
Summary:
while testing https://github.com/facebook/watchman/pull/743 I
noticed that the cmake builds were picking up the installed mingw GCC
compiler rather than the MSVC compiler. That would be fine except that
boost is built with MSVC and its generated libraries cannot be subsequently
found by a cmake gcc build that uses FindBoost.
This commit forces cmake to pick cl.exe rather than gcc. This is probably
fine to do unconditionally on windows, but since I've only observed this
particular problem with GitHub Actions I'm keeping it constrained to that
environment for now.
Reviewed By: simpkins
Differential Revision: D17385050
fbshipit-source-id: 90bef898b138e5d4bbd28a155ed1bd468acee9de
Summary:
We've been squeaking by with assuming that flex is installed already
on posix systems, but that isn't the case on the github actions default
configuration.
Adjust the bison recipe: on windows it deploys both flex and bison. We use the
same source for both flex and bison but install flex to a separate install
prefix to make it easier to consume the flex dependency distinct from the bison
dependency.
The latest flex release segfaults during compilation on linux unless we
force -DGNU_SOURCE, so the manifest does that on linux.
Reviewed By: simpkins
Differential Revision: D17385051
fbshipit-source-id: 9f31b07849af9de50099d1b20bedba517bbbdf2f
Summary:
while testing https://github.com/facebook/watchman/pull/743 on macOS
I noticed that the libevent build failed to find openssl.
openssl is special on macos because apple do not ship the headers.
We already build and depend on openssl for the folly manifest on
macos, so this is really just adding a missing edge.
Reviewed By: simpkins
Differential Revision: D17385053
fbshipit-source-id: 1b688537fef422d81a959fc5749c871b9e868baa
Summary:
We would like to build a version of proxygen that has minimal
dependencies on dynamic libraries.
Reviewed By: yfeldblum
Differential Revision: D17228181
fbshipit-source-id: cfd61afdfa978c49a536184f426502196241fb8a
Summary:
On Windows we have to explicitly invoke `make_fbpy_archive.py` with python.
Therefore use CMake's built-in `FindPythonInterp` module to find the python
executable and use that when invoking `make_fbpy_archive.py`
This is slightly complicated by the effort required to find python with older
versions of CMake. We ideally still want to support versions of CMake back to
at least 3.8, which means we need to still support finding Python with the
older `FindPythonInterp.cmake` module
Reviewed By: wez
Differential Revision: D17128606
fbshipit-source-id: 3f4beff76848b8a362ebdf21198e7a8bf1b0537f
