Date: Fri, 9 Sep 2016 17:27:39 -0700 From: "Simon J. Gerraty" <sjg@juniper.net> To: Bryan Drewery <bdrewery@FreeBSD.org> Cc: <src-committers@FreeBSD.org>, <svn-src-all@FreeBSD.org>, <svn-src-head@FreeBSD.org>, <sjg@juniper.net> Subject: Re: svn commit: r305634 - head/share/mk Message-ID: <76391.1473467259@kaos.jnpr.net> In-Reply-To: <c564348e-59dd-dec8-180e-7a29a4700194@FreeBSD.org> References: <201609090121.u891LZOO023156@repo.freebsd.org> <c564348e-59dd-dec8-180e-7a29a4700194@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bryan Drewery <bdrewery@FreeBSD.org> wrote:
> > +# we can afford to use cookies to prevent some targets
> > +# re-running needlessly
> > +META_COOKIE_TOUCH= touch ${COOKIE.${.TARGET}:U${.OBJDIR}/${.TARGET}}
>
> Could you use ?= here please? I have a META_COOKIE_TOUCH in local.sys.mk
Sure.
> Also note that you need to remove this cookie immediately in any target
> that uses it. I covered this a bit in my BSDCan presentation. The
> problem is if meta mode determines that a target is outdated, then
> partially rebuilds the target, then fails before touching the cookie.
> The next build may not consider the target out-of-date anymore and fail
> to retry.
>
> Consider something like:
> foo: foo.c
> target_install:
> cp foo ${DESTDIR}/usr/bin/
> touch target_install
>
> It may consider this target out-of-date due to foo rebuilding (and
> detected in target_install.meta), but the cp may fail. The next build,
> target_install.meta was overwritten with the failed attempt, and is now
> newer than foo and still has its target_install cookie. Nothing will
The mtime of the .meta file is not relevent as it is not the target
If foo is still newer than target_install and referenced by the the
.meta file the target will still be out-of-date
Sill, one could do things like:
.ERROR:
${.ERROR_TARGET:Drm -f ${.ERROR_TARGET}}
or if multiple things to be done on .ERROR
.ERROR: rm-failed
rm-failed: .NOMETA
${.ERROR_TARGET:Drm -f ${.ERROR_TARGET}}
to ensure that any failed target is removed.
> cause it to retry copying, and it proceeds on with the build without
> properly failing again. I hit this case in at least include/ (which
> went through a lot of further changes, finally of which was the removal
> of cookies in r300346) and some other cases which I don't recall the
> specifics for.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?76391.1473467259>