Even better handling of property changes when restoring a build graph.

In detail:
    - Fix the build config comparison function so that it not only
checks whether keys present in both maps are the same, but also whether
there are additional keys in one of the maps.
    - Do not abort loading a restored build graph when the comparison
fails; instead, handle that condition the same way we handle changes in
build system files, environment variables etc; that is, re-resolve the
project and check whether the build data needs to be set up from
scratch for any products.
    - Take overridden properties into account when comparing the
old and new property maps. This has no effect on the command line
client at the moment, because it does its own merging, but
other API clients will benefit.
A particularly nice "side effect" of this patch is that changing
properties on the command line now works as expected with regards to
change tracking.

Task-number: QBS-374
Change-Id: I55583fb7a2ae78b80de225b09aa559229d851339
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>

1 files changed, 2 insertions, 1 deletions

diff --git a/src/lib/buildgraph/buildgraphloader.h b/src/lib/buildgraph/buildgraphloader.h
index 3086a0217..0335481bf 100644
--- a/src/lib/buildgraph/buildgraphloader.h
+++ b/src/lib/buildgraph/buildgraphloader.h
@@ -63,7 +63,8 @@ public:
 private:
     void trackProjectChanges(const SetupProjectParameters &parameters,
                              const QString &buildGraphFilePath,
-                             const TopLevelProjectPtr &restoredProject);
+                             const TopLevelProjectPtr &restoredProject,
+                             const QVariantMap &oldProjectConfig);
     bool hasEnvironmentChanged(const TopLevelProjectConstPtr &restoredProject) const;
     bool hasFileExistsResultChanged(const TopLevelProjectConstPtr &restoredProject) const;
     bool hasProductFileChanged(const QList<ResolvedProductPtr> &restoredProducts,