svn commit: r253795 - head/sys/modules/usb/runfw

[Bruce Evans]

On Tue, 30 Jul 2013, Sergey Kandaurov wrote:

> Log:
>  Fix up paths after r253790.
>  While here, use $? contraction.
>
>  Reported by:	O. Hartmann
>
> Modified:
>  head/sys/modules/usb/runfw/Makefile
>
> Modified: head/sys/modules/usb/runfw/Makefile
> ==============================================================================
> --- head/sys/modules/usb/runfw/Makefile	Tue Jul 30 07:03:52 2013	(r253794)
> +++ head/sys/modules/usb/runfw/Makefile	Tue Jul 30 08:09:48 2013	(r253795)
> @@ -5,7 +5,7 @@ FIRMWS=	run.fw:runfw:1
>
> CLEANFILES=	run.fw
>
> -run.fw: ${.CURDIR}/../../contrib/dev/run/rt2870.fw.uu
> -	uudecode -p ${.CURDIR}/../../contrib/dev/run/rt2870.fw.uu > ${.TARGET}
> +run.fw: ${.CURDIR}/../../../contrib/dev/run/rt2870.fw.uu
> +	uudecode -p $? > ${.TARGET}
>
> .include <bsd.kmod.mk>

% MAKE(1)                 FreeBSD General Commands Manual                MAKE(1)
% ...
%      Local variables
%              Variables that are defined specific to a certain target.  The
%              seven local variables are as follows:
% ...
%              .OODATE   The list of sources for this target that were deemed
% ...
%              The shorter forms `@', `!', `<', `%', `?', `>', and `*' are per-
%              mitted for backward compatibility and are not recommended.  The

${.OODATE} is less well known that the others.  Actually, it seems to be
just logically wrong.  I think the well-known ${.ALLSRC} is correct.
Whan a single target is built from a set of sources, all the sources
are often required (with the main exceptions being cases like the full
set including headers but the command only acceptiong non-headers as
input files).  A subset consisting of only the out of date sources is
rarely wanted.  But here, as in many simple cases, the full set has size
1, so it is the same as the out-of-date subset unless that is empty.
So both ${.OODATE} and ${.ALLSRC} work, but ${.ALLSRC} is more logical.

Grepping at other uudecode commands in modules makefiles shows a high density
of style bugs and 1 good example for just the uudecode part in 16 files

hpt27xx/Makefile:
hptrr/Makefile:
Null dependency list (so ${.ALLSRC} is null).  The source file .named *.o.uu,
and is named explicitly, starting with the path prefix.  All other source
files are in C and are handled normally, with make(1) adding the path prefix
after finding them using .PATH.  The verbose pathname gives another style
bug (line too long).  The makefile has many other style bugs.  Everything
for the .o.uu conversion could be handled automagically by a suffix rule.

hptmv/Makefile:
Like hpt27xx except the *.o.uu name is in a macro, and the dependency list
is not null.  It is clearer to have the name in a macro, but the ifdef to
define this macro is probably not needed and it handles fewer cases than
in hpt27xx (it translates from ${MACHINE_CPUARCH} instead of using
${MACHINE_ARCH}).

hptnr/Makefile:
Like htp27xx.  1 fewer style bugs since the verbose name is not so long as
to give a too-long line.

mwlfw/Makefile:
Uses $?.  Better general style than hpt*, partly because it is simpler.
But it doesn't use .PATH, so it has to use full (relative) pathnames
involving ${CURDIR}/... in several places.  Has to add the generated
files to CLEANFILES since these are not handled automatically by putting
them in ${OBJS}.  A general .fw.uu suffix rule could handle this
automagically.

nve/Makefile:
Uses ${.OODATE} for the %DIKED file, but duplicates the verbose pathname
for the .bz2.uu file.  Uses .PATH, but now the .uu file is in a subdir
of the directory specified by .PATH.  The verbose pathname is duplicates
this directory pathname and appends the subdir name.  Uses more normal
for SRCS and other normal things (no += for SRCS...), but still has many
style bugs: unsorted SRCS; += for the initialization of OBJS and CLEANFILES;
duplicated (object) file in CLEANFILES; use of WERROR.

runfw/Makefile:
Duplicated a verbose pathname (now uses $?).

wpifw/Makefile:
Duplicates a verbose pathname.  Doesn't even use its .PATH prefix for the
source file name in the dependencies for the .fw.uu file.  The main
component of the pathname is long and cryptic but is quadruplicated.

cxgbe/t4_firmware/Makefile:
cxgbe/t5_firmware/Makefile:
Finally an unbad example.  More complicated (to handle more non-firmware
files).  Uses ${.ALLSRC} for the 1 uudecode rule.  Also uses uudecode -o
instead of uudecode -p.  Still has many style bugs, startting with
'KMOD<space>=<space>' instead of 'KMOD<nowhitespace>=<tab>'.  No tabs
at all except 1 where make syntax requires it (for the uudecode rule).
So, actually a bad example for everything except the uudecode rule.

ipwfw/ipw_bss/Makefile:
ipwfw/ipw_ibss/Makefile:
ipwfw/ipw_monitor/Makefile:
ipwfw/ipw_iwi_bss/Makefile:
ipwfw/ipw_iwi_ibss/Makefile:
iwifw/iwi_monitor/Makefile:
Duplicates a verbose pathname.  Doesnt even use its .PATH prefix...

Bruce