DevelopersPre-alpha

Project structure

Map core, standard addons and workspace directories, replace directives and what you edit day to day.

Three repositories

Sumeru splits engine, standard apps, and your workspace so you can pull core without mixing client code.

Layout

text

1sumeru_erp/2  sumeru/                 # core engine + kernel addons (pull-only)3  sumeru_addons/          # standard business apps (pull-only)4  sumeru_custom_addons/   # your addons, sumeru.conf, make run

Repo	Role	You edit?
`sumeru`	ORM, engine, server, `base`/`mail`/...	Rarely (contribute upstream)
`sumeru_addons`	CRM, sale, account, ...	No for client work
`sumeru_custom_addons`	Custom modules + local INI + generated imports	Yes

Wiring with replace

From the workspace:

Terminal

shell

$make replace-sumeru SUMERU_ROOT=../sumeru$make replace-sumeru-addons ADDONS_ROOT=../sumeru_addons$make generate

addons_path. Discovery still comes from the INI, e.g. addons_path = ../sumeru/addons,../sumeru_addons,./addons. Later roots override duplicate module names.

Day-to-day paths

Models and XML: sumeru_custom_addons/addons/<module>/
Config: sumeru.conf (gitignored; copy from sumeru.conf.example)
Generated: addonimports/zimports.go (do not hand-edit)

Compile and run

Terminal

shell

$cd sumeru_custom_addons$make generate$make run

What not to do

Do not commit generated zimports.go if the workspace treats it as gitignored.
Do not point addons_path only at core when you expect custom modules to load.
Do not fork core for every client. Use the custom workspace.

Next step

Declare module metadata in Manifests & depends.