From 5fb2abf9e95185d812ab202564fac2bf39addece Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Wed, 28 Mar 2018 10:17:26 +0200 Subject: Add "just reconfigure" action to build_package --- bpkg/pkg-build.cxx | 58 ++++++++++++++++++++++++++++++++---------------------- 1 file changed, 34 insertions(+), 24 deletions(-) diff --git a/bpkg/pkg-build.cxx b/bpkg/pkg-build.cxx index b24ac70..89768c1 100644 --- a/bpkg/pkg-build.cxx +++ b/bpkg/pkg-build.cxx @@ -235,7 +235,19 @@ namespace bpkg // Selected package is not NULL, available package is NULL. // - drop + drop, + + // Selected package is not NULL, available package is NULL. + // + // This is "just reconfigure" action for a dependent package that needs + // to be reconfigured because its prerequisite is being up/down-graded + // or reconfigured. + // + // Note that this action is "replaceable" with either drop or build + // action but in the latter case the reconfigure_ flag must be set to + // true. + // + reconf } action; @@ -288,41 +300,39 @@ namespace bpkg // set required_by; - // True if we need to reconfigure this package. If available package - // is NULL, then reconfigure must be true (this is a dependent that - // needs to be reconfigured because its prerequisite is being up/down- - // graded or reconfigured). Note that in some cases reconfigure is - // naturally implied. For example, if an already configured package - // is being up/down-graded. For such cases we don't guarantee that - // the reconfigure flag is true. We only make sure to set it for - // cases that would otherwise miss the need for the reconfiguration. - // As a result, use the reconfigure() accessor which detects both - // explicit and implied cases. - // - // At first, it may seem that this flag is redundant and having the - // available package set to NULL is sufficient. But consider the case - // where the user asked us to build a package that is already in the - // configured state (so all we have to do is pkg-update). Next, add - // to this a prerequisite package that is being upgraded. Now our - // original package has to be reconfigured. But without this flag - // we won't know (available for our package won't be NULL). - // - bool reconf; - bool user_selection () const { return required_by.find ("") != required_by.end (); } + // True if we also need to reconfigure this package. Note that in some + // cases reconfigure is naturally implied. For example, if an already + // configured package is being up/down-graded. For such cases we don't + // guarantee that the reconfigure flag is true. We only make sure to set + // it for cases that would otherwise miss the need for the + // reconfiguration. As a result, use the reconfigure() accessor which + // detects both explicit and implied cases. + // + // At first, it may seem that this flag is redundant and having the + // available package set to NULL is sufficient. But consider the case + // where the user asked us to build a package that is already in the + // configured state (so all we have to do is pkg-update). Next, add to + // this a prerequisite package that is being upgraded. Now our original + // package has to be reconfigured. But without this flag we won't know + // (available for our package won't be NULL). + // + bool reconfigure_; + bool reconfigure () const { - assert (action == build); + assert (action != drop); return selected != nullptr && selected->state == package_state::configured && - (reconf || // Must be checked first, available could be NULL. + (action == reconf || + reconfigure_ || // Must be checked first, available could be NULL. selected->system () != system || selected->version != available_version ()); } -- cgit v1.1