[PATCH] [SUMMARY] (Re: Build under FreeBSD-STABLE broken?)
qhwt at myrealbox.com
qhwt at myrealbox.com
Wed Aug 20 19:38:56 PDT 2003
On Wed, Aug 20, 2003 at 10:07:03AM -0700, Matthew Dillon wrote:
>
> :
> :The first patch(bsd.kmod.mk.diff) modifies bsd.kmod.mk so that it can
> :set SYSDIR properly when .CURDIR is one- or five-level deeper than
> :the top of sys directory, which include:
> : sys/crypto
> : sys/dev/disk/aic7xxx/ahc/ahc_eisa
>
> Ok, I'll commit this one.
Thanks.
> :The second patch(svr4-Makefile.diff) fixes sys/emulation/svr4/Makefile
> :by replacing .CURDIR with .OBJDIR, so that it looks at the files under
> :/usr/obj rather than in the source tree. You never notice if you have
> :write access to the source tree.
>
> I don't think this is correct. Nobody should be regenerating the
> system calls in the normal course of business. The way it works is
> that when a developer changes a system call the developer regenerates
> them and then commits the regenerated files.
Oh, I didn't think of that.
> Is something running these targets during a normal build that
> shouldn't be?
Well... ah, 'sysent' is the first target of sys/emulation/svr4/Makefile,
so running make in sys/emulation/svr4 always tries to regenerate sysent
target. At least other Makefiles under sys/emulation have other rules or
dummy 'all' target. I'm running buildworld/buildkernel again with
following patch.
Index: sys/emulation/svr4/Makefile
===================================================================
RCS file: /home/source/dragonfly/cvs/src/sys/emulation/svr4/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- sys/emulation/svr4/Makefile 15 Aug 2003 06:32:56 -0000 1.5
+++ sys/emulation/svr4/Makefile 21 Aug 2003 02:11:28 -0000
@@ -5,6 +5,9 @@
MAINTAINER= newton at xxxxxxxxxxx
+all:
+ @echo "make sysent only (generates gsvr4_sysent.c svr4_syscall.h svr4_proto.h svr4_union.h)"
+
# This regenerates the system calls
#
sysent: ${.CURDIR}/svr4_sysent.c
Regards.
More information about the Bugs
mailing list