diff options
Diffstat (limited to 'build2/operation.hxx')
| -rw-r--r-- | build2/operation.hxx | 199 |
1 files changed, 12 insertions, 187 deletions
diff --git a/build2/operation.hxx b/build2/operation.hxx index f5a1cf3..1fc6abf 100644 --- a/build2/operation.hxx +++ b/build2/operation.hxx @@ -10,7 +10,9 @@ #include <build2/types.hxx> #include <build2/utility.hxx> +#include <build2/action.hxx> #include <build2/variable.hxx> +#include <build2/prerequisite.hxx> #include <build2/target-state.hxx> namespace build2 @@ -19,195 +21,10 @@ namespace build2 class scope; class target_key; class target; + struct prerequisite_member; struct opspec; - // While we are using uint8_t for the meta/operation ids, we assume - // that each is limited to 4 bits (max 128 entries) so that we can - // store the combined action id in uint8_t as well. This makes our - // life easier when it comes to defining switch labels for action - // ids (no need to mess with endian-ness). - // - // Note that 0 is not a valid meta/operation/action id. - // - using meta_operation_id = uint8_t; - using operation_id = uint8_t; - using action_id = uint8_t; - - // Meta-operations and operations are not the end of the story. We also have - // operation nesting (currently only one level deep) which is used to - // implement pre/post operations (currently, but may be useful for other - // things). Here is the idea: the test operation needs to make sure that the - // targets that it needs to test are up-to-date. So it runs update as its - // pre-operation. It is almost like an ordinary update except that it has - // test as its outer operation (the meta-operations are always the same). - // This way a rule can recognize that this is "update for test" and do - // something differently. For example, if an executable is not a test, then - // there is no use updating it. At the same time, most rules will ignore the - // fact that this is a nested update and for them it is "update as usual". - // - // This inner/outer operation support is implemented by maintaining two - // independent "target states" (see target::state; initially we tried to do - // it via rule/recipe override but that didn't end up well, to put it - // mildly). While the outer operation normally "directs" the inner, inner - // rules can still be matched/executed directly, without outer's involvement - // (e.g., because of other inner rules). A typical implementation of an - // outer rule either returns noop or delegates to the inner rule. In - // particular, it should not replace or override the inner's logic. - // - // While most of the relevant target state is duplicated, certain things are - // shared among the inner/outer rules, such as the target data pad and the - // group state. In particular, it is assumed the group state is always - // determined by the inner rule (see resolve_members()). - // - // Normally, an outer rule will be responsible for any additional, outer - // operation-specific work. Sometimes, however, the inner rule needs to - // customize its behavior. In this case the outer and inner rules must - // communicate this explicitly (normally via the target's data pad) and - // there is a number of restrictions to this approach. See - // cc::{link,install}_rule for details. - // - struct action - { - action (): inner_id (0), outer_id (0) {} // Invalid action. - - // If this is not a nested operation, then outer should be 0. - // - action (meta_operation_id m, operation_id inner, operation_id outer = 0) - : inner_id ((m << 4) | inner), - outer_id (outer == 0 ? 0 : (m << 4) | outer) {} - - meta_operation_id - meta_operation () const {return inner_id >> 4;} - - operation_id - operation () const {return inner_id & 0xF;} - - operation_id - outer_operation () const {return outer_id & 0xF;} - - bool inner () const {return outer_id == 0;} - bool outer () const {return outer_id != 0;} - - action - inner_action () const - { - return action (meta_operation (), operation ()); - } - - // Implicit conversion operator to action_id for the switch() statement, - // etc. Most places only care about the inner operation. - // - operator action_id () const {return inner_id;} - - action_id inner_id; - action_id outer_id; - }; - - inline bool - operator== (action x, action y) - { - return x.inner_id == y.inner_id && x.outer_id == y.outer_id; - } - - inline bool - operator!= (action x, action y) {return !(x == y);} - - bool operator> (action, action) = delete; - bool operator< (action, action) = delete; - bool operator>= (action, action) = delete; - bool operator<= (action, action) = delete; - - ostream& - operator<< (ostream&, action); - - // Inner/outer operation state container. - // - template <typename T> - struct action_state - { - T states[2]; // [0] -- inner, [1] -- outer. - - T& operator[] (action a) {return states[a.inner () ? 0 : 1];} - const T& operator[] (action a) const {return states[a.inner () ? 0 : 1];} - }; - - // Id constants for build-in and pre-defined meta/operations. - // - const meta_operation_id noop_id = 1; // nomop? - const meta_operation_id perform_id = 2; - const meta_operation_id configure_id = 3; - const meta_operation_id disfigure_id = 4; - const meta_operation_id create_id = 5; - const meta_operation_id dist_id = 6; - const meta_operation_id info_id = 7; - - // The default operation is a special marker that can be used to indicate - // that no operation was explicitly specified by the user. If adding - // something here remember to update the man page. - // - const operation_id default_id = 1; // Shall be first. - const operation_id update_id = 2; // Shall be second. - const operation_id clean_id = 3; - - const operation_id test_id = 4; - const operation_id update_for_test_id = 5; // update(for test) alias. - - const operation_id install_id = 6; - const operation_id uninstall_id = 7; - const operation_id update_for_install_id = 8; // update(for install) alias. - - const action_id perform_update_id = (perform_id << 4) | update_id; - const action_id perform_clean_id = (perform_id << 4) | clean_id; - const action_id perform_test_id = (perform_id << 4) | test_id; - const action_id perform_install_id = (perform_id << 4) | install_id; - const action_id perform_uninstall_id = (perform_id << 4) | uninstall_id; - - const action_id configure_update_id = (configure_id << 4) | update_id; - - // Recipe execution mode. - // - // When a target is a prerequisite of another target, its recipe can be - // executed before the dependent's recipe (the normal case) or after. - // We will call these "front" and "back" execution modes, respectively - // (think "the prerequisite is 'front-running' the dependent"). - // - // There could also be several dependent targets and the prerequisite's - // recipe can be execute as part of the first dependent (the normal - // case) or last (or for all/some of them; see the recipe execution - // protocol in <target>). We will call these "first" and "last" - // execution modes, respectively. - // - // Now you may be having a hard time imagining where a mode other than - // the normal one (first/front) could be useful. An the answer is, - // compensating or inverse operations such as clean, uninstall, etc. - // If we use the last/back mode for, say, clean, then we will remove - // targets in the order inverse to the way they were updated. While - // this sounds like an elegant idea, are there any practical benefits - // of doing it this way? As it turns out there is (at least) one: when - // we are removing a directory (see fsdir{}), we want to do it after - // all the targets that depend on it (such as files, sub-directories) - // were removed. If we do it before, then the directory won't be empty - // yet. - // - // It appears that this execution mode is dictated by the essence of - // the operation. Constructive operations (those that "do") seem to - // naturally use the first/front mode. That is, we need to "do" the - // prerequisite first before we can "do" the dependent. While the - // destructive ones (those that "undo") seem to need last/back. That - // is, we need to "undo" all the dependents before we can "undo" the - // prerequisite (say, we need to remove all the files before we can - // remove their directory). - // - // If you noticed the parallel with the way C++ construction and - // destruction works for base/derived object then you earned a gold - // star! - // - // Note that the front/back mode is realized in the dependen's recipe - // (which is another indication that it is a property of the operation). - // - enum class execution_mode {first, last}; - // Meta-operation info. // @@ -309,10 +126,18 @@ namespace build2 void (*execute) (const values&, action, action_targets&, uint16_t diag, bool progress); - // Start of operation and meta-operation batches. + // End of operation and meta-operation batches. // void (*operation_post) (const values&, operation_id); void (*meta_operation_post) (const values&); + + // Optional prerequisite inclusion/exclusion override callback. See + // include() for details. + // + include_type (*include) (action, + const target&, + const prerequisite_member&, + include_type); }; // Built-in meta-operations. |