This is a rewrite of the build system with `jbuilder`, with just a
minimal toplevel Makefile for backward compatibility.
This first patch preserves the project architecture, we only gain
proper dependencies handling and always up-to-date `.merlin` files.
A latter patch may split the project in smaller "sub-package",
i.e. multiple `.opam` files.
The embedded versions of the economic protocol are now compiled with
`jbuilder` instead of `tezos-protocol-compiler`, potentially allowing
proper inlining at the cost of slightly-less-stricter
sandboxing. Nevertheless, dynamically loaded protocol are still
compiled with the `tezos-protocol-compiler` and thus strictly
sandboxed ; and a CI rule also checks the proper sandboxing of
embedded protocols.
This patch is coauthored with @hnrgrgr
This patch is co-authored with: cagdas.bozman@ocamlpro.com
With this patch the economic protocol is now compiled as as
"functor-pack", parameterized over the environment. This will ease the
protocol reusability outside of the tezos source tree (e.g. for a
michelson Web IDE) and will allow proper unit testing of the economic
protocol.
This functorization allows to break the dependency of the
'tezos-protocol-compiler' on various '.mli' of the node, and hence
we don't need anymore the unusual compilation schema:
a.mli -> b.mli -> b.ml -> a.ml
where 'A' is linked after 'B' but 'a.mli' should still be compiled
before 'b.mli'. This will simplify a switch to 'ocp-build' or 'jbuiler'.
It now takes a `proto_header` in parameter, and it returns a full
`shell_header`. This prepares the inclusion of the context's hash in the
`shell_header`.
Let's get serious. The full index of operations is not sustainable in
the production code. We now only keep the index of operations not yet
in the chain (i.e. the mempool/prevalidation). Operations from the
chain are now only accesible through a block. For instance, see the
RPC:
/blocks/<hash>/proto/operations
The minimal header now (classically) contains the root of a Merkle tree,
wrapping a list of lists of operations. Currently, the validator only
accept a single list of operations, but the 3+pass validator will
requires at least two lists.
