[llvm-test-suite] Refactor run script arg parsing to while/case (NFCI)

[jplehr]

Replace getopts with a while/case parser as groundwork for adding long options. Preserves all existing short flags and bundled forms (e.g. -cbt, -j8, -j 8) with no behavior change.

This will be used in follow-up PRs which add support for enabling "heavier" libraris, e.g., --rocprim as additional targets.

[ro-i]

If you use getopt as in /usr/bin/getopt instead of the bash builtin getopts, you get support for long options, see man 1 getopt

[ro-i]

I would avoid hand-parsing options at all costs :D

[jplehr]

If you use getopt as in /usr/bin/getopt instead of the bash builtin getopts, you get support for long options, see man 1 getopt

I am aware of it and found sources saying it's better not to be used. I don't care which way we go.

[ro-i]

I wasn't aware of those concerns, sorry. But claude thinks:

Why the "avoid getopt" advice exists — and why it's mostly outdated

• The warning targets legacy/BSD getopt, which mangled whitespace and empty values (it word-split everything).
• Enhanced getopt (util-linux) fixes this via eval set -- "$(getopt ...)" with proper quoting. It's on essentially every Linux distro.
• Real catch: enhanced getopt is Linux-only; macOS/BSD ship the broken one. AOMP is ROCm → effectively Linux-only, so this is likely a non-issue here. That's the actual reason the folklore persists.

[mhalk]

While I have no clear preference, IMHO this current use-case is perfectly covered by getopts.
We're using shell scripts on different systems and the options are not that plentiful, so I don't see the benefit of getopt.
If we want "better" arg parsing, something tells me: we won't ever find it in a shell script.

Was just about to point out the concerns but Robert already did :)

[jplehr]

While I have no clear preference, IMHO this current use-case is perfectly covered by getopts. We're using shell scripts on different systems and the options are not that plentiful, so I don't see the benefit of getopt. If we want "better" arg parsing, something tells me: we won't ever find it in a shell script.

The reason I'm doing this is to enable us to include long-options, e.g., --rocprim, --kokkos, --ginkgo and similar, which to my understanding getopts does not cover.

[mhalk]

Sorry, that flew by me and I was only scanning the code -- it is actually hard to understand this intent TBH (at least for me).
Then getopt might actually be a good option AFAICT.

[jplehr]

Switched the whole thing over to using getopt

[mhalk]

LGTM!

[ro-i]

nice, thanks!