Skip to content

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:

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:

Hello.nxproject
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:

Hello.Forge.nxscript
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.

Hello.Setup.nxscript
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.