LinuxCNC Documentation

СИНОПСИС

halcompupdate [--in-place] [--no-backup] [--check] [--quiet] compfile…​

ОПИСАНИЕ

halcompupdate converts HAL components written for the legacy HAL API (pins and params declared with the types float, bit, s32, u32, s64, u64, signed or unsigned and written with plain C assignment) to the new HAL API, where pins and params are declared with the types real, bool, si32, ui32, sint and uint and written with the generated <name>_set(value) accessor.

halcompile(1) still accepts the legacy declaration types with a warning, but plain C assignment to a pin or parameter no longer compiles.

The following transformations are applied:

  • Declaration types are replaced: float → real, bit → bool, s32 → si32, u32 → ui32, s64 → sint, u64 → uint, signed → si32, unsigned → ui32. si32 and ui32 keep the current 32-bit behaviour, and each one is noted with its line number. They are a stopgap: the component must then be made 64-bit clean, moving them to sint and uint. That requires an analysis of the code: a value that passes through 32-bit intermediate storage or a 32-bit calculation is silently truncated, so every local variable, intermediate result, cast and helper function parameter a pin value passes through must be checked, as must every place that relies on the 32-bit range or on wrap-around. The type port is not converted yet.

  • Assignments to out and io pins and to parameters are rewritten to the <name>_set(…​) form, including compound assignments (name += x becomes name_set(name + (x))), increments/decrements and array pins (name(i) = x becomes name_set(i, x)).

  • Dereferences of the old pin pointer macro are rewritten: name_ptr reads become (name) and name_ptr = x writes become name_set(x).

The C types in the component are left alone. The legacy hal_*t types no longer exist. They were volatile values, nearly always wrong as variables, and only the author can tell, so each use is reported with its line number and left for manual conversion. A pointer to one of these types needs the same evaluation: a plain type or, for a pin or param, a reference with *hal_get and *hal_set_. A conversion that compiles is not a checked one: review the diff and test the component.

Reading pins and params is unchanged: the bare name (or name(idx) for arrays) evaluates to the value in both APIs.

Pin and parameter names are never changed, because they are part of the HAL configuration interface used by .hal files. A name that spells out a legacy type, however, is pointed out: halcompupdate notes every name - of a pin, a parameter, the component or a function - that contains a segment naming a legacy type (float, bit, s32, u32, s64, u64) and suggests the new-style spelling, for example out_s32 → out_sint or conv_s32_float → conv_sint_real. The component name is the loadrt/loadusr argument and the module name, and functions are exported as comp.N.function, so a renamed component or function name affects existing configurations as well. The note is optional, does not modify the file, and does not affect the --check exit status; the author decides whether the word in the name really meant the type (a pin named sel-bit counts bits of a value, a pin named float_switch is a hardware float switch).

Components that use the legacy hal_pin_*new/hal_param*_new creation functions directly, or that pass the address of a pin (&name) to helper functions, cannot be converted automatically. halcompupdate prints a warning for those cases so they can be converted by hand.

After each file a summary line reports how many mechanical changes were applied, how many constructs were left for manual review, how many pins and parameters were kept 32-bit, and how many names mention a legacy type (optional rename); if nothing needed to be converted, it reports the name notes only. Always review the diff and test the converted component before use.

ОПЦИИ

compfile…​

One or more .comp files to convert. Without other options, a unified diff of the required changes is printed.

-i, --in-place

Rewrite the files in place. A backup with the suffix .bak is kept unless --no-backup is given.

--no-backup

With --in-place, do not keep a .bak backup.

--check

Do not write anything; exit with status 1 if any file would be changed. Useful in build systems to verify that components are migrated.

-q, --quiet

Suppress warnings and notes on stderr.

EXAMPLES

Show what would change:

halcompupdate mycomponent.comp

Migrate in place:

halcompupdate -i mycomponent.comp

СМОТРИТЕ ТАКЖЕ

halcompile(1), the Halcompile / HAL Component Generator section in the LinuxCNC documentation for a full description of the .comp syntax and the new HAL API.