Practical applications
The same language relationships appear in different consumers. The consumer adds domain meaning; it does not replace references, composition, or filtering with a separate language.
A catalog application
The learning sequence already provides two complete application paths:
- Regional selection and the native reader select the applicable product and follow its Featured relationship.
- Catalog generation and the manifest produce several text artifacts from shared information.
The first consumes a graph. The second consumes its presentation. Choose the path according to whether the application needs to retain live relationships or produce a finished artifact.
A Nexus Build application
Use hello.pas from Your first Nexus application and save this project beside it:
dialect "projects/nxbuild/language/nxbuild.Language.nxscript";
module Tools "NXBuild.Environment.nxscript";
Project Hello {
Id: "Example.Hello";
NXPC Application (Tools.Defaults.Pascal) {
SourceFiles: ["hello.pas"];
OutputPath: "build/" + $TargetOS;
}
}
Run nxbuild /action=build /project=Hello.nxproject /targetos=win64 /targetcpu=x86_64
on Windows, or select linux on Linux.
Here the module supplies shared definitions, composition selects the Pascal defaults, and the external reference reads the selected TargetOS. Nexus Build's consumer knows how to compile SourceFiles and use OutputPath. Its loader supplies the installed environment-file fallback. That fallback is a Nexus Build feature, not a general rule that any missing module can be found beside a tool.
Nexus Forge assembly
Save beside Hello.nxproject:
dialect "projects/forge/language/Forge.nxscript";
Project Delivery {
Id: "Example.Delivery";
NXBuild Application { EntryPoint: "Hello.nxproject"; }
CreateDirectory Package { Path: "package"; }
CopyFile Program TargetOS[win64] {
Source: "build/win64/hello.exe";
Destination: "package/hello.exe";
Overwrite: True;
}
CopyFile Program TargetOS[linux] {
Source: "build/linux/hello";
Destination: "package/hello";
Overwrite: True;
}
}
Run:
nxforge /input=Hello.Forge.nxscript /targets=TargetOS:win64,TargetCPU:x86_64,BuildConfiguration:Debug
Select TargetOS:linux on Linux. Both Program declarations represent the same
copy task; target filtering chooses one. Nexus Forge interprets the compiled Project
by executing its children in order. Nexus Build remains the project compiler.
Declaration order matters here because Nexus Forge defines ordered task execution. The Nexus Script language itself does not execute CopyFile while resolving the document, and it does not guess the executable's suffix.
A Setup definition
After the Nexus Forge example has produced package/hello.exe, save the following.
Replace <Nexus installation> with the actual installation root using forward
slashes. Setup needs this explicit dialect path; the Nexus Build loader's installed
dialect fallback is not a language-wide rule.
dialect "<Nexus installation>/scripts/projects/setup/language/Setup.Language.nxscript";
Product Hello {
Id: "Example.Hello";
Name: "Hello";
Version: "1.0.0";
Publisher: "Example";
Location Application { Kind: ApplicationRoot; }
Feature Runtime {
Required: True;
File Program {
Source: "package/hello.exe";
Location: @Hello.Application;
Path: "hello.exe";
}
}
}
Validate it without installing anything:
NexusSetupBuilder --validate Hello.Setup.nxscript TargetOS=win64 TargetCPU=x86_64
Location is a reference to an existing definition. Setup interprets ApplicationRoot, Required, and File; the dialect checks their allowed shapes. Compilation does not choose an installation folder or install the file. The Setup guide describes the installer workflow.
The sample's source filename is explicitly Windows-specific. A Linux recipe would declare its Linux source/path or select corresponding File alternatives. It should not change the meaning of the shared Runtime feature or use platform-specific names to simulate target selection.