Introduction and Overview
Beyond ordinary compiling and linking, some projects need an extra generated component as part of the build: a module header and veneer produced from a CMHG description, a language header generated from an assembler-style constant definition, or an ALF object library assembled from existing objects. These are still build-time concerns, covered separately from Building, linking, and outputs because they only apply to certain project types.
Generated build assets
Building modules with CMunge
RISC OS modules normally add one more generated component to the build: a CMHG or CMunge description file that defines the module header, command table, SWIs, services, and generated veneers. The riscos-cmunge wrapper reads that description, produces the veneer object and generated C header, and then the rest of the module is built and linked in the usual AMU flow.
In a conventional project, the description file lives in a cmhg/ directory and produces outputs such as o/modhead and h/modhead. The description syntax itself is summarised in Appendix G: CMHG file format.
For a direct build step, the CMunge wrapper is typically invoked like this. The -px switch is required whenever the description file uses C preprocessor directives such as #include "VersionNum", which the generated skeleton always does; without it, CMunge fails with Unknown preprocessor command encountered: #include "VersionNum":
riscos-cmunge -px -32bit -throwback -o o32.modhead -d h.modhead cmhg.modhead
CMunge 0.86 (JRF:0.86.109) [25 May 2026]
Copyright (c) 1999-2025 Robin Watts/Gerph
Norcroft RISC OS ARM C vsn 5.18 (JRF:5.18.134) [Mar 5 2026]
ARM AOF Macro Assembler 3.32 (JRF:3.32.44) [07 Mar 2006]
The exact tool version banners will vary between environment releases. -d h.modhead only produces a header file when the description actually declares something that needs one, such as a SWI chunk or command table; a minimal module with neither produces no header file and that is not an error.
Once the generated header and veneer object exist, AMU or the makefile rules compile the module sources and link them with the veneer object into rm32/ or a related module output directory.
Generating language headers from assembler definitions
The RISC OS source tree and related interface exports often describe constants in assembler-style .hdr files rather than in C or other language-specific forms. The riscos-hdrtoh tool converts those simple definition headers into generated constant files for other languages.
This is most commonly used to generate C headers from the standard RISC OS assembler headers, but it can also emit BASIC, Pascal, Python, and Fortran forms. It is intended for conventional constant-definition headers, not for arbitrary assembler source with complex conditional logic.
Typical uses are. Both tools are silent on success:
riscos-hdrtoh Interface/OSPlatformFeatures h/OSPlatformFeatures
riscos-hdrtoh -format BASIC Interface/OSPlatformFeatures OSPlatformFeatures,ffb
riscos-hdrtoh -many -swisonly -o h.swis hdr.swis hdr.extra
Use -many when several input headers should contribute to one generated output file, -silent <file> when one header depends on definitions from another but should not itself be emitted, and -swisonly when only SWI-related constants are wanted. With -many, the output file must be given explicitly with -o; without it, the tool cannot tell which of the trailing filenames is the output and reports the usage syntax instead of running.
Building and inspecting ALF libraries
The Norcroft toolchain uses ALF library archives for collections of object files and related members. The riscos-libfile tool is used to create and maintain those archives, especially when preparing object libraries for later use with riscos-link.
For object-library work, the important distinction is whether the archive also needs an external symbol table. When the library is intended for the linker, use -o so the symbol table is generated or refreshed. When you are only extracting or inspecting a library, that symbol table is usually not needed.
Typical uses are. -c and -i are silent on success; -l -s lists the library contents and the external symbol table together:
riscos-libfile -c -o mylib o/*
riscos-libfile -i mylib o/newmodule o/support
riscos-libfile -l -s mylib
Format version: 1
Last Modification: Sun Jun 21 15:52:02 2026
Contents
o/newmodule 292 Sun Jun 21 15:51:57 2026
o/support 292 Sun Jun 21 15:51:57 2026
End of Library
External Symbol Table, generated: Sun Jun 21 15:52:02 2026
func1 from o/newmodule
func2 from o/support
End of Table
riscos-libfile -e mylib ?sort*
Extraction recreates any directory components in the member name relative to the current directory, so a member such as o/support needs the o/ directory to already exist before extracting, in the same way that compilers and linkers need their output directories to exist first.
Be careful when archiving directories or broad wildcards. Directories are added recursively, so an incautious create or insert operation can capture far more of a source tree than intended. For distribution libraries, also prefer relative pathnames rather than absolute ones, so extraction is not tied to one machine's directory layout.
If you need more control over how member names are transformed while building or unpacking a library, use riscos-makealf instead. It can read object names from list files, extract objects from existing libraries, and apply explicit name-translation rules while writing either a new library or a directory of extracted members.