Macro subsocial_runtime::construct_runtime [−][src]
construct_runtime!() { /* proc-macro */ }
Construct a runtime, with the given name and the given modules.
The parameters here are specific types for Block
, NodeBlock
, and UncheckedExtrinsic
and the modules that are used by the runtime.
Block
is the block type that is used in the runtime and NodeBlock
is the block type
that is used in the node. For instance they can differ in the extrinsics type.
Example:
construct_runtime!(
pub enum Runtime where
Block = Block,
NodeBlock = runtime::Block,
UncheckedExtrinsic = UncheckedExtrinsic
{
System: system::{Module, Call, Event<T>, Config<T>} = 0,
Test: test::{Module, Call} = 1,
Test2: test_with_long_module::{Module, Event<T>},
// Module with instances
Test3_Instance1: test3::<Instance1>::{Module, Call, Storage, Event<T, I>, Config<T, I>, Origin<T, I>},
Test3_DefaultInstance: test3::{Module, Call, Storage, Event<T>, Config<T>, Origin<T>} = 4,
}
)
The identifier System
is the name of the pallet and the lower case identifier system
is the
name of the Rust module/crate for this Substrate module. The identifiers between the braces are
the module parts provided by the pallet. It is important to list these parts here to export
them correctly in the metadata or to make the pallet usable in the runtime.
We provide support for the following module parts in a pallet:
Module
Call
Storage
Event
orEvent<T>
(if the event is generic)Origin
orOrigin<T>
(if the origin is generic)Config
orConfig<T>
(if the config is generic)Inherent
- If the module provides/can check inherents.ValidateUnsigned
- If the module validates unsigned extrinsics.
= $n
is an optional part allowing to define at which index the module variants in
OriginCaller
, Call
and Event
are encoded, and to define the ModuleToIndex value.
if = $n
is not given, then index is resolved same as fieldless enum in Rust
(i.e. incrementedly from previous index):
module1 .. = 2,
module2 .., // Here module2 is given index 3
module3 .. = 0,
module4 .., // Here module4 is given index 1
Note
The population of the genesis storage depends on the order of modules. So, if one of your modules depends on another module, the module that is depended upon needs to come before the module depending on it.