Target-aware workspace configuration
2ot keeps compiler profiles and vendor-specific integration concerns explicit, while machine-local SDK paths and endpoints stay outside the public source model.
Configuration follows the target
The compiler and integration layers are organized around distinct target profiles and vendor backends. Configuration tells the routed toolchain which environment a calling harness is working with without exposing the internal helper scripts used to exercise that environment.
Compiler-level choices
Target selection affects parsing, semantic handling, lowering and backend behavior. 2ot supports Siemens TIA, TwinCAT, CODESYS and Rusty target paths, so configuration can remain target-aware without turning vendor implementation details into public product concepts.
Machine-local integration settings
Vendor SDK locations, IDE installations and local bridge endpoints vary by machine. Those belong in environment- or host-specific configuration rather than in portable product documentation or examples that imply one fixed setup.
Supported configuration concerns
| Concern | Why it matters |
|---|---|
| target profile | Selects the dialect and backend behavior used by the compiler. |
| vendor integration | Connects target-aware compiler output to Siemens TIA, TwinCAT or CODESYS integration surfaces. |
| local SDK / IDE | Machine-specific installation details that should remain host-local. |
| diagnostics | Feeds checking, compilation and automation/agent feedback without coupling docs to one transport. |
Keep docs at the product boundary
The site intentionally avoids hard-coding private pipe names, script hosts, executable paths or transient implementation details. Those can change independently of the stable harness-facing concepts: target, compiler, validation, integration and diagnostics.