diff options
| -rw-r--r-- | bpkg/pkg-build.cxx | 58 |
1 files 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<string> 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 ()); } |