Re: [PATCH] [SUMMARY] (Re: Build under FreeBSD-STABLE broken?)

[qhwt@xxxxxxxxxxxxx]

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?