Age | Commit message (Collapse) | Author |
|
Simplify the logic somewhat by copying all packages in a manifest
as soon as one is found which fails the pkg-diff comparison.
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
|
|
Possibly temporary workarounds to facilitate an initial build:
* Prevent do_package_compare being run for native packages (this is
a hammer to prevent trying to run build-compare on the
build-compare-native package)
* Prevent do_package_compare being run for recipes where PACKAGES
is empty (this was to prevent trying to run do_package_compare
on gcc-source, which has no packages)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
|
|
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
|
|
When a dependency causes a recipe to effectively be rebuilt, its output
may in fact not change; but new packages (with an increased PR value, if
using the PR server) will be generated nonetheless. There's no practical
way for us to predict whether or not this is going to be the case based
solely on the inputs, but we can compare the package output and see if
that is materially different and based upon that decide to replace the
old package with the new one.
This class effectively intercepts packages as they are written out by
do_package_write_*, causing them to be written into a different
directory where we can compare them to whatever older packages might
be in the "real" package feed directory, and avoid copying the new
package to the feed if it has not materially changed. We use
build-compare to do the package comparison.
(NOTE: this is still a work in progress and there are no doubt
unresolved issues.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|