You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
`! ...` is simpler, as well as easier to read in `just` output.
The `if ...; then false; else true; fi` syntax seems to have been
introduced in 72cf940, in a command that, at that time, was in the
`Makefile`.
It's unclear if there was a reason to prefer it at the time it was
introduced. Both a `Makefile` and a `justfile` work fine with `!`
as it is used here, in both cases it is preserved literally and
passed to the shell, and in both cases the shell is by default `sh`
on all systems.
It looks like `!` may have been avoided to accommodate behavior of
`bsdmake` (which was at one time the default `make` on macOS, and
which remains the default `make` on various other systems), where
at least in some versions an optimization to run commands without a
shell is triggered even in the presence of a leading `!` and even
though `!` is a shell keyword. This does happen today if `bsdmake`
is installed on macOS via `brew`, but only with *simple* commands,
as in a rule like this (if one fixes the indentation, to use tabs):
hello:
! false
Then:
$ bsdmake hello
! false
!:No such file or directory
*** Error code 1
Whereas, with...
hello:
if false; then false; else true; fi
...the shell is used and it succeeds:
$ bsdmake hello
if false; then false; else true; fi
However, this does not establish that the practice was needed even
when the command was in a `Makefile`, because with...
hello:
! false >/dev/null
...the presence of the redirection operator `>` is sufficient to
cause a shell to be used, and it succeeds:
$ bsdmake hello
! false >/dev/null
All commands negated via `if ...; then false; else true; fi` in the
history of `gitoxide` in the `Makefile` (as well as after they were
moved to the `justfile`) seem to have used `>` redirection, because
the point is to verify that a build command that should fail does
fail, and it is distracting to show the full compiler output of the
intended failure. So it seems `!` negation could have worked even
with versions of `bsdmake` where it does not always work, and even
when the commands were in the `Makefile`. (Though it may have been
avoided in order to make immediately clear to human readers that no
`!` misinterpretation would occur.)
In any case, this is not in a `Makefile` at all anymore. Using `!`
works locally and on CI, is easier to read, and the output is
easier to understand, both in general and specifically in how it
lines up with the explanatory comment. The output now looks like:
# assure compile error occurs
! cargo check --features lean-async 2>/dev/null
! cargo check -p gitoxide-core --all-features 2>/dev/null
! cargo check -p gix-packetline --all-features 2>/dev/null
! cargo check -p gix-transport --all-features 2>/dev/null
! cargo check -p gix-protocol --all-features 2>/dev/null
0 commit comments