shards build --mcpu causes lookup of CPU arch as a target incorrectly

[ziggythehamster]

Problem

shards build incorrectly treats --mcpu as if you specified --target (also, separately, --target on shards build makes --target on crystal build not available directly).

Reproduce

As an example, if you were trying to optimize the build for Graviton2:

$ shards build --production --no-debug --release --stats --verbose --mcpu neoverse-n1 --mattr +crc,+fp16,+rcpc,+dotprod,+crypto
Dependencies are satisfied
Error target neoverse-n1 was not found in shard.yml.

Workaround

There is a workaround (which also permits you to set --target):

CRYSTAL_OPTS="--target aarch64-linux-gnu --mcpu neoverse-n1 --mattr +crc,+fp16,+rcpc,+dotprod,+crypto" shards build --production --no-debug --release --stats --verbose

[straight-shoota]

The bug is caused here:

shards/src/cli.cr

Lines 132 to 142 in 85b30b5

	def self.parse_args(args)
	targets = [] of String
	options = [] of String
	args.each do |arg|
	if arg.starts_with?('-')
	options << arg
	else
	targets << arg
	end
	end

All arguments that don't start with a dash are considered a target.

A simple workaround is to write flag and value as a single argument: --mcpu neoverse-n1. Or just use crystal build directly.

Related: crystal-lang/crystal#11136

[straight-shoota]

For a proper fix, I think it doesn't make sense to expect targets at arbitrary positions. Everything after the first flag argument (starting with dash) should simply be forwarded to crystal build.
There could also be a -- to separate targets from forwarding options.
Example: shards build mytarget othertarget -- --mcpu neoverse-n1. This should definitely be allowed, maybe even required.

[ziggythehamster]

A simple workaround is to write flag and value as a single argument: --mcpu neoverse-n1

Did you mean --mcpu=neoverse-n1?

Example: shards build mytarget othertarget -- --mcpu neoverse-n1

I agree that this is how it should behave, because shards build --production target1 target2 -- --release --no-debug --some-other-args-which-shards-doesnt-care-about has a logical behavior that other CLI commands (e.g., git) follow. The "flags are forwarded to crystal build and don't show up in help" thing is a bit surprising, whereas stating that anything after -- is passed directly to crystal build isn't.

It also allows for Crystal to change without Shards having to. e.g., if Crystal added a --split-debug filename option so that debugging symbols can be generated as a separate file for dropping into /usr/lib/debug or whatever the OS prefers, then Shards doesn't have to know that.