[chiliec]

Summary

Two build-time changes, one with a large wall-clock effect and one small frontend win, plus a test.

1. CMAKE_OPTIMIZE_DEPENDENCIES ON (root CMakeLists.txt, libraries/chain/CMakeLists.txt)

With the Unix Makefiles generator a target does not start compiling until every target it links is fully archived. For static libraries that is pure serialization: nothing in graphene_chain starts until fc and graphene_protocol are done, and no plugin starts until database.cpp (the longest TU, ~80 s at -O2) finishes alone on one core. Executables still wait for everything they link.

CMAKE_OPTIMIZE_DEPENDENCIES (CMake >= 3.19; CI runs 3.28) removes those edges for static libraries while keeping dependencies on custom-command outputs and anything declared through add_dependencies. Two things in libraries/chain were defeating it and are removed:

• add_dependencies(graphene_chain graphene_protocol graphene_utilities ...): the library-to-library edges already come from target_link_libraries; only build_hardfork_hpp is a real build-order dependency.
• the generated hardfork.hpp listed as a source of graphene_chain.

Resulting graph (checked in the generated Makefile2): graphene_protocol depends on project_secp256k1 only; graphene_chain and every plugin depend on project_secp256k1 and build_hardfork_hpp only; vizd keeps all 33 of its dependencies.

Cold make -j8 vizd cli_wallet, same tree, same flags, M1 laptop:

	wall	user	cores busy
before	805 s	1762 s	~2.4
after	305 s	1375 s	~4.8

Caveats: a fanless laptop throttles under a long serialized tail, which inflates the baseline; 4-vCPU CI runners will gain less because they have less idle capacity to fill. The direction is not in doubt: the critical path was fc -> protocol -> database.cpp -> plugins -> link, and it is now database.cpp -> link.

Ninja users are unaffected (Ninja already orders static libraries this loosely).

2. fc submodule bump to VIZ-Blockchain/fc#6

static_variant's position/type_info helpers were recursive class templates, so every TU that names all 107 operation alternatives paid O(N²) instantiations in the frontend. They are now constexpr functions over a pack-expanded array. Dispatch is unchanged; operations.o is byte-identical before and after, and a round-trip digest over every alternative is identical. ops.cpp 8.4 s -> 6.7 s; database.cpp unchanged (it is backend-bound).

A jump-table dispatch was tried and rejected: it tripled operations.o and slowed database.cpp ~15%. Details in the fc PR.

3. tests/consensus_sim/scenarios/test_operation_variant.cpp

New operation_variant suite: for each of the 107 alternatives, set the tag, raw pack/unpack, to/from fc::variant, copy/move/assign, checking which() throughout; pins vote=0, transfer=2, validator_equivocation=count-1; out-of-range tags rejected via set_which and via raw unpack. This is the guard for any future change to static_variant or to the order of operations.hpp.

Checks

• Full make of every target on the pruned graph: exit 0 (confirms no missing generated-file dependency).
• ctest -E '^consensus_sim$': 13/13 pass.
• consensus_sim_tests -t operation_variant: pass; whole binary links and lists 135 cases.
• fc header check compiles with Apple clang 17 and GCC 13 at -std=c++14 -Wall -Wextra.
• vizd --version from the optimized build runs.

Merge order

fc#6 first, then this PR (the submodule pointer here already targets the fc commit).

[chiliec]

CI timing note: the job durations on this PR (Docker build 10 min; tests 15/15/10 min) match PR #227's run (14/15/10 min). CI job time is dominated by ccache state, test runtime and image layers, not by compile ordering, so the win reported above is for cold/uncached builds (local dev, Docker production image, cache misses after a header change). No regression on CI either.