I have current from a month ago imported into cvs and I am bringing
forward from previous private code a device-independent signal
strength facility (which I intend to share).  I defined new ioctls in
sys/sys/sockio.h, and from-scratch builds are ok.

I changed the name one of my new ioctls and redid the build (with
existing objdirs and -u).  I got a failure in usr.bin/kdump compiling
ioctl.c.  This is a generated file, built from all the .h files.  The
timestamp of sys/sockio.h (in destdir) is newer than ioctl.c (in the
objdir), so it needs to be rebuilt.  But the .depend (in the objdir)
has this:

ioctl.o ioctl.ln: ioctl.c /n0/gdt/SINEW-current/netbsd/src/sys/sys/param.h \
  /n0/gdt/SINEW-current/netbsd/src/sys/sys/null.h \
  /n0/gdt/SINEW-current/netbsd/src/sys/sys/inttypes.h \
  /n0/gdt/SINEW-current/netbsd/src/sys/sys/stdint.h \
  /usr/obj/sinew/destdir/i386/usr/include/machine/int_types.h \
[rest trimmed]

I see  a dependency line in Makefile-ioctl.c:

.if !target(cleandir) && !target(obj)
DEPFILES != grep -l '_IO.*(' ${DEPFILEGLOB}
.endif

ioctl.c: mkioctls ${DEPFILES}

but this seems not be working.  I am guessing DEPFILES is ok because
the list in .depend looks ok.

I run build.sh like this:

===> build.sh command: ./build.sh -m i386 -O /usr/obj/sinew/i386 -D /usr/obj/sinew/destdir/i386 -R /usr/obj/sinew/releasedir -T /usr/obj/sinew/tools -u distribution
===> build.sh started: Fri Mar 12 18:09:43 EST 2004
===> MACHINE:          i386
===> MACHINE_ARCH:     i386
===> TOOLDIR path:     /usr/obj/sinew/tools
===> DESTDIR path:     /usr/obj/sinew/destdir/i386
===> RELEASEDIR path:  /usr/obj/sinew/releasedir
===> makewrapper:      /usr/obj/sinew/tools/bin/nbmake-i386

so I can do builds on 1.6.2 or current.

I ran 'nbmake-i386 -d A' and found no trace of DEPFILES in the output.

Obviously I can add a 'nbmake-i386 clean' in that dir (and the other 2
similar ones) to my system-level build script, but this behavior seems
incorrect to me.  I'm not much of a make(1) weenie, and I have no idea
what to look at.


-- 
        Greg Troxel <gdt@ir.bbn.com>