the implementation stuff in a variable CTFCONVERT_RUN
- introduce an OBJECT_TARGET variable that contains the output object file
- when we need to run ctfconvert, go through an intermediate ${.TARGET}.o
file, instead of writing directly to ${.TARGET} and then overwriting
${.TARGET} with ctfconvert. This avoids build failures after a build
got interrupted (the "partially built from C" scourge).
It needs the (8), or it fails to work for people who don't know or had
forgotten catman(8) was ever a thing.
as the de facto fortunes editor and also I think the person who added
that fortune in the first place, and given the discussion in
tech-userlevel, I think I get to do this.
The lint option affects much more than a typical debug flag. Not only
does it produce additional diagnostics, it also changes the control flow
and fixes the traditional error handling in a few places.
No functional change.
at least a few pkgsrc packages avoid base sqlite because it fails
this check, and it's probably a surprising performance penalty for
unsuspecting users
Mention VARE_WANTRES before VARE_UNDEFERR since the latter depends on
the former.
In ApplyModifier_Assign, VARE_KEEP_DOLLAR doesn't have to be removed
from eflags since ParseModifierPart does this already.
In EvalUndefined, testing for VARE_WANTRES is redundant if VARE_UNDEFERR
is already set.
There are only 3 flags, and some combinations don't even make sense.
VARE_UNDEFERR only makes sense if combined with VARE_WANTRES. If the
latter is not set, the variable expressions are only parsed, without
asking whether they are defined or not. Therefore, VARE_UNDEFERR cannot
have any effect in that case.
VARE_KEEP_DOLLAR is actively ignored by ParseModifierPart. In cases
where VARE_WANTRES is not set, this means that VARE_NONE can be passed,
which is easier to grasp than any bitset operations. This also gets rid
of a few type casts from enum to unsigned int that were necessary to
pass WARNS=6.
The other flags in VarEvalFlags already describe their effects, not the
place where they are used. It's more important to know the effect.
Only a single unit test had to be adjusted. This probably means that
there are too few tests where the special effects of VARE_KEEP_DOLLAR
come into play. It could also mean that the effects are so simple and
obvious that they don't need any debug log, but that's not the case.
