On Nov 12, 2014, at 3:07 PM, NGie Cooper <yaneurab...@gmail.com> wrote:
> On Thu, Nov 6, 2014 at 9:21 AM, Garrett Cooper <yaneurab...@gmail.com> wrote: >> On Nov 6, 2014, at 9:19, Warner Losh <i...@freebsd.org> wrote: >> >>> Author: imp >>> Date: Thu Nov 6 17:19:41 2014 >>> New Revision: 274186 >>> URL: https://svnweb.freebsd.org/changeset/base/274186 >>> >>> Log: >>> Ignore errors from rm -rf to support high -j builds. This is, at best, >>> a kludge. However, it also effectively works around the issues for >>> high -j builds on systems that do not have the rm fixes. >>> >>> A better fix would be to rmdir here, and fix the places where we're >>> sloppy and not list all the files we create in CLEANFILES, should >>> anybody have the time to chase them all to ground. >> >> I’ll say that bsd.progs.mk is a huge problem here because CLEANFILES is >> handled <number of PROGS> times. >> >> Dealing with bsd.progs.mk and its recursive nature is quite entertaining... > > Another question related to this commit... > > Why aren't return codes ignored for rm -f ${CLEANFILES} ? Because those don’t race each other like the directories do. > bdrewery@ ran into an issue at $work where the build failed after > r268376 because he ran into ESTALE with rm: > > 13:51 <@bdrewery> rm: fts_open: Stale NFS file handle That should fail. If you have weird errors, it should fail, this is a weird error. > This commit will allow the build to continue when dealing with ESTALE > on directories, but it won't fix the case where we hit ESTALE with > CLEANFILES. So? You’ll hit the failure with CLEANFILES soon enough. But as mentioned in the commit message, better fixes are possible. I suggest that this has taken more of my time than is has returned in benefit at this point. Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
