Split build system into library and driver

1 files changed, 202 insertions, 0 deletions

diff --git a/libbuild2/action.hxx b/libbuild2/action.hxx
new file mode 100644
index 0000000..9fa2a16
--- /dev/null
+++ b/libbuild2/action.hxx
@@ -0,0 +1,202 @@
+// file      : libbuild2/action.hxx -*- C++ -*-
+// copyright : Copyright (c) 2014-2019 Code Synthesis Ltd
+// license   : MIT; see accompanying LICENSE file
+
+#ifndef LIBBUILD2_ACTION_HXX
+#define LIBBUILD2_ACTION_HXX
+
+#include <libbuild2/types.hxx>
+#include <libbuild2/utility.hxx>
+
+#include <libbuild2/export.hxx>
+
+namespace build2
+{
+  // 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;
+
+  LIBBUILD2_SYMEXPORT ostream&
+  operator<< (ostream&, action); // operation.cxx
+
+  // Inner/outer operation state container.
+  //
+  template <typename T>
+  struct action_state
+  {
+    T data[2]; // [0] -- inner, [1] -- outer.
+
+    T&       operator[] (action a)       {return data[a.inner () ? 0 : 1];}
+    const T& operator[] (action a) const {return data[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};
+}
+
+#endif // LIBBUILD2_ACTION_HXX