Re: CVS commit: src/usr.bin/make
On Thu, 25 Jan 2024 20:02:00 +0100, Roland Illig writes:
>>> Modified Files:
>>> src/usr.bin/make: make.1
>>>
>>> Log Message:
>>> Indicate that for :U newval is optional
>>
>> I think this is more confusing than helpful.
>
>I agree. Make doesn't distinguish between an empty string and an absent
>string here, so the wording in the manual page should be kept equally
>simple.
Not a question of what make likes or not, but what users glean from the
man page (those that don't also read the source).
The change was prompted by a user (not a make novice by any means)
complaining that :Unewval and the description provides no clue
that just :U is actually valid.
>If anything, you might mention that newval may be empty, but then you'd
I think I started with that, but then figured someone sufficiently
pedantic might consider that not the same as no value being provided ;-)
>have to add the same wording in many other places, for consistency:
>* the variable name in ${:Uvalue}
This is covered by the above no?
>* the two branches of the ':?' modifier in ${cond:?}
true
>* the pattern matching modifiers after ':S,from,to' (1gW)
>* the variable name in the variable assignment '!=3Dcmd'
>* the argument of a function call in '.if defined()'
>
>Most of these cases don't need this wording, and the '!=3Dcmd' case
Agreed, the :S usage at least is sufficiently familiar to anyone who's
used sed(1) to not need elaboration.
Is there perhaps a general statement somewhere (I may have missed it)
that could cover all these and be cited to pedantic users?
Eg to the effect of perhaps, unless stated otherwise arguments to
modifiers are optional or can be empty.
I don't think its there and is hard to word succinctly.
Thanks
--sjg
Re: CVS commit: src/usr.bin/make
On Thu, 25 Jan 2024 21:12:20 +0100, Roland Illig writes: >them all. Due to this, I'd go with: > >> .It Cm \&:U\| Ns Ar newval >> If the variable is undefined, >> .Ar newval >> (which may be empty) is the value. That's almost exactly what I had in my 1st cut ;-) Will do. >Then, add the same wording to ':D' and maybe to ':N' (since ':N' is a >shortcut for the more common ':M*') but not to ':M' itself (as that >would always result in an empty string, making it uninteresting). Will take a look, but not so sure. --sjg
Re: Detecting typos in makefiles (was: Re: CVS commit: src/share/mk)
On Sun, 15 Jan 2023 19:14:14 +0100, Roland Illig writes:
>It is really unfortunate that make didn't catch this typo by itself.
>
>.if ${MACHINE_ARCH} =3D=3D "x86_64" || \
> ${MACHINE_ARCH} =3D=3D "i386" || \
> ${MACHINE_ARCH} =3D=3D "alpha" || \\
> !empty(MACHINE_ARCH:Maarch64*) || \
> !empty(MACHINE_ARCH:Msparc*)
>
>(The 'alpha' line has a trailing '\\' instead of the usual '\'.)
Yes warnings would be good I think.
FWIW the above is why I encouage use of :N to reduce the complexity of
conditionals (eaier to extend without screwing up) as in:
.if ${MACHINE_ARCH:Nalpha:Ni386:Nx86_64} == ""
is equivalent to the first 3 lines above.
Re: CVS commit: src/usr.bin/make
On Sun, 30 Jan 2022 14:54:25 -0500, Christos Zoulas writes: >> Since usr.bin/make is also used in tools/make, it needs to follow the >> rules in tools/README, which say that all tools should stick to C89. >> The format specifier %zu comes from C99 though. > >Yes, %zu is annoying because windows does not have it either (until very >recently I think). But cygwin does have it(?) so there is no issue? size_t is annoying ;-) >> Or can we drop the C89 rule from tools/README? In the past few years, >> usr.bin/make used several features from C99 (end-of-line comments, = >long >> long, %zu, snprintf), and nobody cared to fix the C99-isms, so either >> nobody needed the C89 restriction or we simply ignored the complaints. > >I think that we should ask in tech-toolchain. Yes, I prefer to require = >c99 >at this point. For bmake I have converted the %zu to %u. I no longer have access to even a tiny fraction of the systems bmake is used on, but I recall %z being an issue in the past. I cannot find docs on gcc-2.95 (which is the oldest compiler I've recently had to use to port bmake), and the license for that VM has expired, it probably should support c99 but I cannot confirm. --sjg
