Open ziggythehamster opened 2 years ago
The bug is caused here: https://github.com/crystal-lang/shards/blob/85b30b5755b5aad8e5b4bd94cc94610c6a617bea/src/cli.cr#L132-L142
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
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.
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.
Problem
shards build
incorrectly treats--mcpu
as if you specified--target
(also, separately,--target
onshards build
makes--target
oncrystal build
not available directly).Reproduce
As an example, if you were trying to optimize the build for Graviton2:
Workaround
There is a workaround (which also permits you to set
--target
):