How is <sub> specified in the -target option argument?

Help
1

I took an initial peek at doing commandline completion for zig build-exe -target <TAB>.
The help for this gives

  -target [name]            <arch><sub>-<os>-<abi> see the targets command

The potential values for <arch>, <os> and <abi> directly correspond to “sections” the output of zig targets, but <sub> doesn’t appear as a section. All the examples in the doc seem to use a value for <arch> as is (i.e. without <sub> part).

Are there any examples of the use of <sub> somewhere? Without them the questions I have about <sub> are:

  1. I assume <sub> is optional. Is that correct?
  2. If providedm does this have to be a value taken from .cpus? E.g. if <arch> would be x86_64, are the possible <sub> values: alderlake, amdfam10, arrowlake, etc.?
  3. How <arch> and <sub> concatenated? Is there a dash or underscore between them, or just glued together?

I intend to process the output from zig targets into a static definition (so it will require an update zigclc if a target is added), and not handle this on the fly (like I do with the zig build steps, project specific options, and system integration options. That is simpler to implement/faster, and the zig targets output only changes with a new version. Or am I missing something and should this be made dynamic for some reason?

I did look at the parsing code, where strings are converted to enum. I am not sure but that looks to me as if there is no <sub> part parsing at all.

2

I believe that <sub> was a mistake in the --help string.
The 7 years old commit that introduced <sub> says:

-target [name] instead of --target-* args.

and indeed it creates a single --target triple for the options --target-os, --target-arch, and --target-environ (environ becomes abi).

1 Like
3

You missed the relevant part:

stop hiding the concept of sub-arch. closes #1526

2 Likes
4

I cannot believe that this was two lines bellow and I didn’t realize it.
By the way, there are two related proposals:

1 Like