Date: Sun, 24 Jan 2021 12:00:36 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Needless work in buildworld Message-ID: <09E14666-C661-411F-93A0-78366EA1A21E@yahoo.com> In-Reply-To: <20210124190640.GA90418@www.zefox.net> References: <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> <20210122011535.GA66611@www.zefox.net> <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> <C502D267-5158-4658-BB02-EC67835015D3@yahoo.com> <36A2E015-78DF-40AB-BF53-FB3D26FA5AAC@yahoo.com> <20210122224656.GA76907@www.zefox.net> <2903491E-7DE7-4F17-B515-120BA447B8B3@yahoo.com> <A982C6D4-6123-40FA-8592-A3CD7B0D8E10@yahoo.com> <20210123173754.GA83834@www.zefox.net> <EDF9F631-FF55-444C-BAB3-3037CEA61D65@yahoo.com> <20210124190640.GA90418@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-24, at 11:06, bob prohaska <fbsd @ www.zefox.net> wrote: > On Sat, Jan 23, 2021 at 10:01:07PM -0800, Mark Millard wrote: > [huge snip] >>=20 >>=20 >> The dependency tracking builds up to the final things being built, >> not from the final things backwards.=20 >=20 > That is likely the cause of my confusion. There's a natural "trail of > breadcrumbs" leading from the final product back upstream, via the=20 > dependencies. I thought that's what META_MODE followed. Is there=20 > something going the other way, source to object to installed binary,=20= > as well? That seems difficult. The author of a book can't readily > guess who will cite it. =20 The "trail of breadcrumbs" is involved, but just because a breadcrumb needs to be updated does not mean that all the other breadcrumbs for the final product need to be updated. Think of it in (simplistic) stages: A) figure out what breadcrumbs are involved, no matter if they need updating or not: final product back to the dependencies. B) figure out which of those breadcrumbs need updating: via a valid "reverse" order headed back to the final product. (Going back "up" a tree/Directed-Acyclic-Graph structure, the order is not necessarily unique.) Note: (A) and (B) can form a recursive structure instead of strictly separate stages. It was easier to describe simply as separate stages. (B) only rebuilds what it needs to as it goes along. Going "up" the "tree", a node/breadcrumb is not updated if the judge-relevant contributing inputs are unchanged. Makefile content and filemon file usage tracking are part of establishing (A). (See more notes later.) >> It frequently is the case >> that only some of the chain required for a final thing is rebuilt. >> As an example: A final link may reference a mix of changed and >> unchanged material, for example. But that final link is required >> if any of its inputs changed. Unnecessary changes to inputs might >> lead to a relink that otherwise would not be needed. >>=20 >>> I >>> can readily see how this would avalanche, but it seems necessary. = Have=20 >>> I got at least that part right?=20 >>=20 >> The "avalanche" reference and implication fits my alternate wording >> as well as yours and so is good, whatever the other details of the >> avalanche structure may be. >>=20 >>>>> The files (programs) were used during the activity that generated = the prior >>>>> build of the target. The worry is that the updated programs might = have >>>>> differing results from older ones and so the new timestamps lead = to >>>>> rebuilding. The worry is just unlikely to be an actual problem for = many of >>>>> the particular programs. >>>>>=20 >>>>> It would be good if META_MODE could ignore those programs that are = in the >>>>> legacy area and are unlikely to cause the output to vary in some >>>>> significant way. >>>>>=20 >>>=20 >>> Is this to say that META_MODE is checking outside the dependency = chain >>> (web?), reacting to files changed but not to be used again? >>=20 >> I'm not sure of the reference/context-intended here. >>=20 >> See the prior libc++.a example above for an example in >> which the timestamp on . . ./tmp/legacy/usr/sbin/rm is >> irrelevant to if the libc++.a actually needs to be >> rebuilt. >=20 > Well, if META_MODE is looking at things that don't matter anymore, > that would be outside the dependency chain. If those things matter, > but only conditionally, one can either check for the conditions or > recompile, whichever is easier. Checking conditions will get messy.=20 > Perhaps that's the whole problem 8-) The issue is more that figuring out what matters vs. does not matter becomes more non-trivial the more biased to avoiding unnecessary rebuild steps the process becomes. In the "rm" example, the mere fact that rm was used happens not be sufficient to require the rebuild based on rm being newer. Rebuilding more than required would still produce valid results. So this is just about that bias to rebuilding less. That rm was used is being tracked and used to choose to rebuild, which is suboptimal, not wrong. Bryan D. may well just decide that it is not worth the effort to be more biased to avoiding unnecessary rebuild steps for the issue that I reported. For buildworld buildkernel on a RPi2, that would continue to be to be rather noticeable. But buildworld buildkernel being more timely on a RPi2 is not a requirement for FreeBSD so far as I know. He would probably judge based on possibly helping other types of contexts. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?09E14666-C661-411F-93A0-78366EA1A21E>