From owner-freebsd-arm@freebsd.org Sun Jan 24 20:00:40 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 80B894D86D6 for ; Sun, 24 Jan 2021 20:00:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DP3lC48t0z4WSH for ; Sun, 24 Jan 2021 20:00:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611518437; bh=XHQ8eNMqC/3odTJihGGbJkzUqNI4Z9JG3rXXFbUVsaK=; h=Subject:From:Date:To:From:Subject:Reply-To; b=lAhTP1lq0J4V0hs8o9nywSpfsAohF59uXi8Wf4kdmF5LuOf0h1BYz3MEa0CkaF0T1AGGaHtXS5UsuQeyKCDfcDA8coMTaWqJw9D8Se+vdP+3Kr165wF+D4bylddflt0jXkKJb1flxqQhzyOZMZvWGIhbzwsrIMF2lMkkOca/60cCOdZg2YzVO0s76czJWruYin5Xgo9rH5c+cpsd7irqoyLULWr6pG69xrJTRNGe9Bfh0XjI2eIgz+pEZrLZdF/ROSyyHUltRmji79yZ/2XmuAica3YbBKFPAKjPeWjcruszom4pw64pmU+Z8C9MBm0Je6hvxJz72ODFllXp+H73Ig== X-YMail-OSG: w6z5MDkVM1mLGQoJgoJYLAfl0KWbnNykHHVOFY_4HzXNz1tww2Hpbu_orP78opX 3pm2mAAgC_06MWOgzHC8R21IrcGT5Joa07GmZgE_yafZslVD9OgVK17m7khSenLJR5xRYUmCo_h4 RXe1bdGXQ7pyasqar4xpfWQJNCl.Ri0DjZneegYD_28LqJ.IqF3lSh6iMNQOkG9BJ5b4v9FS1LZV ZFiWhpYiH3wC6QYJDSwyvB0biyBbE2.noCIgPiOdLzfAbZlqB0c.UbaeC6IIL3YS.WRlyvyAYK_u EGJ4K.5cJNC1lbwGioJV_H3cqNROAM75qV8wPbsR28DLJq_mBy8wJwIJsgPNtkWCVLHM5kIuBwUq OnQnxW8lgAgSq.yca1RH78SRKRRrkMpgK7NDQwH.OvMMKsBXPBivPuxjweGdEHMQxeCHAZs9k_IT 56iv5VUXkove6BqS2a79XY9o2uoagbrGX481FQAirlckLUZQ9HNHXNm57IobeD_59b0llh4tEqWB it4cIHAajyVPPChziDJJJ3oZkSkERW47p.aMB4sRbXCykgW0uJgR3Cje8N7unnDmgvc6nIUJvsSX y5dYFn.4C2vzTXvM4SSpXZZDB6.s9EZjm7sZsm1jBForIEf4m1o4DYJavjbro5ACCGzMNrqkBp_W _qKs_AI7sy4Lw_Oq2OgxHhb31V62XYrngs2qh6CKEBcl7jeraSbjLk.j0FiHxNhIvkgC6XDlbmBB GHgQkH1rGrOlBLHX_ENP6qbQeSESod.5aQrtLwgz6wJrfQBhg3ry1ng7UWt0F_cjfLSPmVpP_OCR Y4t_FU5RDNnZjy3nVXdr8M3OxsKqPfJeRoATr6q4iUykgKLTcuz0VCqcrCHhUylO_4IiSoXvf0FY 2y2cFLhCozGcOOpbW8GFs3I8cAr0K1QLIBjtb12PUieAaBSjs2aNf_PfL0uqZZrseglAKAtWCcmH qZq.b3w4GQykFkMiiysREk6niK9lNSIcyIHetMCCrWjIKz1HC8cTenUmB_jDNgnN6fBqwJ3kk8NT hf8MJJnYSvr5X08TXoiWWOJVUgNDkHDWjSE4cdeA1kuhKsCdT8uB3v5ChrKNptF9Z9fAjU11i_sb uKy1JBhM0QsxhAvKe0wjDutQY7oArwxWRMUysE4DweLdmShtpit6j2KM5HP2MLX2mjr2rzLYBD81 gFu4sdNzu6zFsuJcIteCe5fFLx70ATc3E5ryautKLMBsCw9eCzxK3jwVrdTehCxV.Wse_yv.4XrD QZ1WExcpLhDqz5aJ0PChEO8skNW.NstuptrHgs2Y2uzW_CPeAMSFdtQEqsp1MbfbCo1JTCeVEbYl ycJyCnyNNkxLrsPDAS_RCczcHMfAKxASHqe5r.Dfml2LYlKQGHHNT2Ri8iXpq.aVVf2neScz.SUB wD7muksGHNBNCs255Wu5QQk.uHKQGjha0BJbi4Gbh0iGQVnaOF.69dZVF09DH4PdFTslYZCgMgzq lAz.gJho9KpnvwsMVHEYVCh6lJnCJef2huVn4dB01cwlDksj62vjTn4IvvAHO2AWHuhRdwjF4VSd VjI6BuFBPOg_jo2RaqdWg9PJOXgIq8Ralu5YyWkLfEEqdVunYAwfuv8VJkn1S.a2MOuMNK2TBSCd gm3bS0YSVS8sy3pS2x8WACnAz484DKhcUGYpbLCBQyfvinNNGyYV2HuPSSa5AX99VgoFUblkcPLA 5ZIEurl7NXGEpQNWjdjfRHG1D_nC98iD0m99xA4P2A1O4AobhmzFESXF0mVNKpMWgsMs1eqUENFC 06jKUf1ExVVR8nJsfvEV21qNhffkkWWM_jiU4lQYMTzamVvbVdXIax3IbotXIgt17YsKweBMKqGU dSYI1kptI7Rj8thplFeQ9ddFdR9iwxcYp98suB3TqoRPmxQDAqdL4wXo7nWQUVaedEVWxQLZwsXI H.wTz7sg_sBhwlcrw9WGA3T4i455bpfoHBDxfuHmwAUEUl7fBfFysxgi0d0Dds.XpMlPNimGV3zl XCfdZkxy6A9QIBzk9h52uGawKxXr04RVqvg9_C9ToWOjI3NHp9xSINZ3ig.A2huetrQVz.F0BYdu 26WjjdQBXPthDAAVyxB2lsRf2EwYAXgGGX_p__7REbo1VKhj1.L6kO4_bahqGp33JN5TzhtjU_El yuLXgGwyjqaPF8kJug9n_aFZZmHBhwGmxjMhPY.qnE76oqrU_NhJXfdEDTaccRJ9twpW2ehj2cQF LmAlAd9ACp_fxRrY_S.jJkEeCWB520Ob8foRK0pPajq42qjw7wD2ENSebRSmDuTJZRmQI3Sx_AyJ wNsRUJV1AC5E8dzoTCy_35nPaYPp8uYYNIZLXA2ZcxHA4eLyxs1B2PWIz32DYOKX6NgzIUNHP0p5 Gk_AKiDEKskm33EDyt5xbIYVRQUAVsaq3W072gm3drpOxp0PsQzas1a1gLeYSVm_dVW21VlVA8js yN9WjOSHUJ30sCOG1zb.h26KbB4tpZXKZsnzuRlzYCvLEv3P2XCwpta4JJStgkVeXs.E8.ODBYKB 81L6K Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sun, 24 Jan 2021 20:00:37 +0000 Received: by smtp407.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a20583fad00d3a8bc0d06c9458c9fbb8; Sun, 24 Jan 2021 20:00:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Needless work in buildworld From: Mark Millard In-Reply-To: <20210124190640.GA90418@www.zefox.net> Date: Sun, 24 Jan 2021 12:00:36 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <09E14666-C661-411F-93A0-78366EA1A21E@yahoo.com> References: <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> <20210122011535.GA66611@www.zefox.net> <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> <36A2E015-78DF-40AB-BF53-FB3D26FA5AAC@yahoo.com> <20210122224656.GA76907@www.zefox.net> <2903491E-7DE7-4F17-B515-120BA447B8B3@yahoo.com> <20210123173754.GA83834@www.zefox.net> <20210124190640.GA90418@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DP3lC48t0z4WSH X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.55 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.05)[-0.054]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.148:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2021 20:00:40 -0000 On 2021-Jan-24, at 11:06, bob prohaska 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)