Skip to content

Recommended Workflow

XSMP Modeler supports several ways of working, but the most productive user workflow is usually the following.

1. Start with a project

Create or open a project with:

  • the VS Code wizard
  • or an existing xsmp.project

Declare the project sources, profile and tools first. This gives the editor enough context to validate the rest of the workspace correctly.

2. Define your types in catalogues

Start modeling in .xsmpcat files:

  • value types
  • enumerations
  • interfaces
  • models
  • services

Catalogues are the foundation for everything else.

If you already have SMP XML sources, you can also place .smpcat, .smpcfg, .smplnk, .smpasb, or .smpsed files directly in a project source folder. XSMP Modeler imports them automatically for editing, validation, and generation workflows. If a real XSMP source file and an SMP source homologue exist side by side, the XSMP file wins.

3. Add runtime documents as needed

Use the other XSMP languages when the project grows:

  • .xsmpcfg for reusable configuration data
  • .xsmpasb for instantiated systems
  • .xsmplnk for reusable link wiring
  • .xsmpsed for schedules and activities

Not every project needs all of them.

4. Reuse examples

The repository examples/ directory is a good place to study realistic structures:

  • 01-foundation
  • 02-avionics
  • 04-orbital-segment
  • 06-mission-system

Those examples show how catalogues, configurations, assemblies, links and schedules fit together.

5. Validate early

Use validation continuously in the editor and fix issues as soon as they appear.

6. Generate outputs

In VS Code, you can either rely on automatic generation on save when xsmp.generateOnSave is enabled or run commands explicitly:

  • Xsmp: Generate Project
  • Xsmp: Generate All Projects

Generation uses the active profile and tools of the target project.

Each generation compares its outputs with the files on disk. Unchanged files keep their timestamps; missing files are recreated and manually edited generated files are restored from the model. Unexpected files are removed only inside folders wholly owned by a generator, such as src-gen or include-gen, after successful generation. Keep handwritten code in generation-gap source folders or other user-owned folders, not in generated folders.

In mixed Python/helper folders, only previously generated files recorded in .xsmp/generated-files.json are removed when obsolete. User files created only once are preserved and their content is not rendered again while they exist. Keep the .xsmp/ metadata directory out of version control. Without a usable inventory, unknown files in mixed folders are preserved.

This also applies to the first generation after opening a workspace, whether or not xsmp.generateAllOnStartup is enabled. Editing a generated C++ file does not trigger generation: the next generation triggered by an XSMP save or an explicit command updates it.

7. Keep project boundaries clear

When a project depends on another project:

  • the modeling documents of the dependency become visible
  • but the dependency's active tools and profile do not become active in the dependent project

That separation keeps large workspaces predictable.