Summary:
fboss-oss build links to hash that corresponds to tag v4.4.0 released on Jan 11 2016
```
repo_url = https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
rev = 92a0236a3cdf3438000834121b7ea8a09f1f52b1
```
The change is to update the iproute2 version to ```v4.12.0``` (July 5 2017) to match with the version used internally to Facebook
Reviewed By: shri-khare
Differential Revision: D21411714
fbshipit-source-id: fac606396e284193bb7199cf60d2601594bfa5f0
Summary:
D21364132 accidentally broke this; we can't run the fetcher
for projects for which we pulled the build out of cache, because there
is no source to update in that case.
This commit adjusts the logic so that we write out a marker file
to indicate that we installed a build from cache and to look for
that file being present to gate the new update logic.
Reviewed By: lnicco
Differential Revision: D21419122
fbshipit-source-id: 304670848add22531d88549d66f22c40ff255140
Summary: The oss jobs are causing problems to the developers now, lets disable them temporarily.
Reviewed By: StanislavGlebik
Differential Revision: D21400898
fbshipit-source-id: f7a3567056633d9eef98a8d05a37cd029c9e506c
Summary:
When the commit hash changed in fbsource, we would correctly decide
that we'd need to rebuild first-party projects but we would incorrectly skip
running the fetcher.update method. This would mean that we'd not perform the
shipit run and that our shipit tree would diverge from the source tree.
This commit resolves this by performing the fetcher.update but ignoring
the source update status in this case.
Reviewed By: xavierd
Differential Revision: D21364131
fbshipit-source-id: b4001e549c7d3f27aa4a21b19893c9bb7c0f6d1f
Summary:
We didn't do a great job of recognizing that we'd need to
build a project when one of its dependencies had changed: we relied
chiefly on the dependency hash for this and could fail to handle
changes in individual source files.
This commit helps to improve this situation by checking to see if
any installed files in the dependencies of a manifest are newer than
the most recent built time of a given manifest. If so, we'll trigger
a build. We try to be reasonably smart about deciding when to trigger
a cmake reconfigure if it looks like cmake files in the deps have
been changed.
Reviewed By: xavierd
Differential Revision: D21364132
fbshipit-source-id: 7534496e10d1f532aa9cf865900ace84a8785327
Summary:
Only run cmake reconfigure for .cmake, .cmake.in and CMakeLists.txt
files changes.
Previously we would reconfigure for any change to a file with a path that
matched `cmake` which could result in false positives in cases where
you may be iterating on .py or .c files in shared cmake directories.
This also reclassifies non-cmake files under fbcode_builder/CMake as source
files so that we run cmake for those; previously they would cause a
reconfigure and build, now they just cause a build.
Reviewed By: xavierd
Differential Revision: D21364133
fbshipit-source-id: a1231f657d6c6056b269656c677d3449d8715cf6
Summary:
Our linter really wants to include formatting changes unrelated
to my diff stack.
This is a formatting only change to avoid clouding my diffs; no functional
effect.
Reviewed By: xavierd
Differential Revision: D21364519
fbshipit-source-id: 7670dd4154e788f593f256aabdfdeef6d17aeec4
Summary:
Previously getdeps would remove the entire top-level `CMakeFiles` directory
from the build output when it wanted to invalidate the CMake cache. This
directory is used to keep all of the compiled object files for any libraries
or executables defined in the top-level CMakeLists.txt file. Blowing away
this directory forces all of these sources to be re-compiled, even if this was
not necessary. This is particularly problematic for folly, which compiles all
of its source files via rules in the top-level CMakeLists.txt target file.
I did have the code still blow away the CMake error and output logs in this
directory: in the past I have seen situations where CMake would not update
these files on new CMake runs if they already existed.
Reviewed By: wez
Differential Revision: D21360668
fbshipit-source-id: 6fcd1a8e371d756114fbab60d8636be8cd5f8978
Summary:
Update the manifest file for folly to indicate a dependency on lz4.
folly does not require lz4 be available, but it will use it if it is found at
configure time.
getdeps is unfortunately not strict about providing projects only with the
dependencies that they require at build time. This causes it to sometimes
make lz4 available to folly (if you are also building another project that
requires lz4), and sometimes not. This ends up causing changes in
folly-config.h depending on which projects you are building, forcing all of
the folly sources to be recompiled.
In the future we perhaps should update getdeps to consistently only pass in
include directories for dependencies actually listed in the manifest file.
However, specifying that folly depends on lz4 also works to mitigate this
particular issue for now, and it is also generally desirable to build folly
with lz4 support.
Reviewed By: wez
Differential Revision: D21359995
fbshipit-source-id: aaf61671b7750d6c47e3613c732d220b3311b5ba
