DragonFly bugs List (threaded) for 2003-08
Re: [PATCH] [SUMMARY] (Re: Build under FreeBSD-STABLE broken?)
On Thu, Aug 21, 2003 at 11:37:10AM +0900, qhwt@xxxxxxxxxxxxx wrote:
> > :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
No, this patch is completely bogus. The reason these four files
svr4_sysent.c svr4_syscall.h svr4_proto.h svr4_union.h
got updated during buildkernel was that they have timestamps older than
sys/kern/makesyscalls.sh . After touching these files, svr4 built just file.
So the question is: shouldn't the newer version of these files, after
doing 'make sysent', be committed?