From nobody Tue May 06 15:15:43 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZsMRH3fCGz5txwB for ; Tue, 06 May 2025 15:15:55 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZsMRH3Djnz3grT for ; Tue, 06 May 2025 15:15:55 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746544555; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VMALnJpg3XnmuGhDtESdDQLgb5rSq5X4pRFRJ3Dg9qY=; b=jB67L0FkBIeDt/i9osmPC49D2SFyMfuuZQsgyeigoqKy+7Ko93hJXm6mLYdFW49b72j4n4 hTTviS7Q/L8nYqYCsEA9BZaBcFb5cfBEHn9/9yTy291B5F1iHtYATFFQvQrMzDPgs0pxcm br5D6PQpvAA/rxsDodm3R2LYd0ego1b0Xy/HfmQCKrshpFwmFK+TSrDyXd1F94/hkgJEpx RaIquo/horoWVg2imMXQXfMI2DQacSTdMvkTXzxzsvRx1fRFl6pgpuH3/W8VQjyh22dIJI ZFXW6CEedAY4IWZlxQdqLBxCerSLMlj2FypyICIWPIzWmjJpsgnEn+UceO3tPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746544555; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VMALnJpg3XnmuGhDtESdDQLgb5rSq5X4pRFRJ3Dg9qY=; b=FLsWoHjRpVKk6ouvHqY5UOMkzOThrKzHvWpYo71hXLDRqnItXRgtiRYA42/0Lg50caMgvm /daxt34A2vorCDMaRzsK3FSZjYiCv2Pzr4qtNYLMMN02Fu4Xi7cHyARNo898dfjRwVJRIJ XC6muttRE0FKkZISE0CgdikXmq18x4KSJQpbAOegiS4uGVKKqwZs553x0ScxBUC+Jn2qft tEfRUWCeixg/T8HnmbuqKTFPNtyQ6OPk4F6zS7O0v6LITsmjjn7U9ai9H1XLfnzqyIpffm gqq6BI49mkKrzWCn1zQL8MK3WKqbCYDKQ21TTI392E3FTsW/rCNPskY9WIfi/w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746544555; a=rsa-sha256; cv=none; b=K23gYEBJkNRhJbEkoIULwWTLYTJPakaSX5Vt3RJfBu9SoO/8kZHDtC+iFnX9w5wZySTNzu khrJ+gSnNOOOIkhOj/ovGTSq3XI3gT0hmyCJosfBwiGyJWKrM1bwp30LQdQaA5r2ce6XrR N5VV0AD6JoUXiqo72dK8fi7cKpBmZtrJRSyO+iCtaF60MER4CKaSTZ4wi/Cht1be3On/aL KtHBvxm5I1EE96ESPUC/uSudxBhH9Iwe8QggoksrxRpqnxNKTl15hWm58S4WEc9uLfgDT/ 080Ikni0Jt8oLLpMd8OSCaxx8W/6Pea8l7/9lcjlCowHk3Ca75LzglR0dl3Dyg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZsMRH2m6fzrsk for ; Tue, 06 May 2025 15:15:55 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-476a2b5dffcso11833581cf.3 for ; Tue, 06 May 2025 08:15:55 -0700 (PDT) X-Gm-Message-State: AOJu0YyS4j5wPnnrH43ygl1Oxm2Wa3hI8mtLwSWy/hQKMG8maeMdrwd1 5k8ms6AQEoTBFr8cpZRmN6pVpNJdsABd0wegyU05T+SVu70FpM59yfKBo6B1ETcA5FrFUqbdM8G M60ZiTkkwdptNSZMRx3hph3cUvhU= X-Google-Smtp-Source: AGHT+IECeDky7P7PHTyJ+IV6uvcpgZHXWdOsG/Pp/IpAIPO1SChEVSX5YYhDD8VWApTANzV5rMzuPi7/WUoho4/FgNs= X-Received: by 2002:a05:622a:353:b0:476:af54:503f with SMTP id d75a77b69052e-48c30d7c6bbmr100013731cf.2.1746544554533; Tue, 06 May 2025 08:15:54 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> In-Reply-To: <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> From: Nuno Teixeira Date: Tue, 6 May 2025 16:15:43 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: ATxdqUEGwZGOkC5Z2rg63sfazwDC4i146CkMEcL0rVD3A49FKSv_hwKdUBgC2Cg Message-ID: Subject: Re: incremental bulds from scratch with beinstall.sh To: Mark Millard Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000c1ed180634791702" --000000000000c1ed180634791702 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Mark, Definitely I'm not getting the results I want with WITH_META_MODE using BEs since most of the times I end up rebuilding almost everything in new BE. Should I stop using WITH_META_MODES a go straight to clean builds (clean /usr/obj) instead? My first concern is to speed up builds expecially on rpi4. Any hints are welcome. Thanks, Mark Millard escreveu (segunda, 5/05/2025 =C3=A0(s) 23:= 18): > Nuno Teixeira wrote on > Date: Mon, 05 May 2025 20:37:09 UTC : > > > (...) > > > > Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not mess wit= h > > ports and stuff. > > > > Nuno Teixeira escreveu (segunda, 5/05/2025 =C3=A0= (s) > > 21:34): > > > > > Hello, > > > > > > Using incremental WITH_META_MODE builds, after installation with > > > beinstall.sh, building same src, a complete compilation happens. > > > > > > If someone uses this script, could you please do the following test: > > > > > > WITH_META_MODE=3Dyes (/etc/src-env.conf) > > > filemon module loaded > > > > > > # cd /usr/src > > > # make buildworld-jobs buildkernel-jobs > > The above used older commands and files from before > the following install. META_MODE recorded the use of > those commands. > > Example .meta mode file content: > > # Meta data file > /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++/l= ibc++.a.meta > CMD @echo building static c++ library > CMD @rm -f libc++.a > CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o > charconv.o chrono.o condition_variable.o condition_variable_destructor.o > debug.o exception.o filesystem/directory_iterator.o filesyste > m/int128_builtins.o filesystem/operations.o functional.o future.o hash.o > ios.o iostream.o locale.o memory.o mutex.o mutex_destructor.o new.o > optional.o random.o random_shuffle.o regex.o shared_mutex.o > stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o > utility.o valarray.o variant.o vector.o cxxrt_auxhelper.o > cxxrt_dynamic_cast.o cxxrt_exception.o cxxrt_guard.o cxxrt_libelftc_dem_g > nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o cxxrt_typeinfo.o > CWD /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc= ++ > TARGET libc++.a > -- command output -- > building static c++ library > > -- filemon acquired metadata -- > # filemon version 5 > # Target pid 22471 > # Start 1611359217.214996 > V 5 > E 22961 /bin/sh > R 22961 /etc/libmap.conf > R 22961 /var/run/ld-elf.so.hints > R 22961 /lib/libedit.so.7 > R 22961 /lib/libc.so.7 > R 22961 /lib/libncursesw.so.9 > R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE > F 22961 22962 > E 22962 > /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/rm > R 22962 /etc/libmap.conf > R 22962 /var/run/ld-elf.so.hints > R 22962 /lib/libc.so.7 > R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE > D 22962 libc++.a > X 22962 0 0 > . . . > > So META_MODE has lots of files that were used > that it can later detect being newer than the > prior build results, leading to rebuilds based > on those newer files. > > > > # ./tools/build/beinstall.sh > > The new be will have various updated files > that could be different by content and, for > commands, could behave differently than those > used to do the prior build. Detecting newer > time stamps on such used files leads to > rebuild activity. > > More than /usr/src/ and /usr/obj/ content > are involved as well. > > Note that the new be is based on somewhat > different files than the original > buildworld-jobs buildkernel-jobs was based > on. > > > > # reboot > > > > > (I presume booting into the new be here.) > > > > # cd /usr/src > > > # make buildworld-jobs buildkernel-jobs > > META_MODE will notice when commands are used > that are newer than when the prior build was > done. Similarly for other files that may be > read. It will make sure that the newer commands > and files are allowed to produce new results > that potentially could be distinct in content > from what the old context produced for results. > > > > > > > Since src and obj are the same from one BE to newer BE, minimal > > > compilation should happen, not a full one. > > META_MODE is more careful than that. > > Note: I'm not claiming that new behavior that is > needed is likely for lots of the files with new > dates. But META_MODE is biased to avoiding leaving > in place something that should have been updated. > > > > > > > Am I missing something here? > > > > > Note that make has a -dM option: > > M Print debugging information about =E2=80=9Cmeta=E2= =80=9D mode > decisions > about targets. > > So, for example, > > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/awk' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/cap_mkdb' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/cat' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/cp' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/crunchgen' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/crunchide' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/dd' > is newer than the target... > . . . > > Various . . ./tmp/legacy/. . ./*bin/ actually were > links to files. > > Ultimately buildworld then installworld lead to new > dates for a bunch of files used. Later use of > META_MODE notices such and rebuilds based on the > newer files. (It is a lot of detail to go through > it all.) > > Back in 2021 and 2023 I got help with exploring > avoiding lots of these. But, in the end, it > involved use of experimental code in > share/mk/src.sys.obj.mk to provide a new > definition to use to build some paths with. > > The experiments were an unsupported activity that > produced an unsupported change to allow > configurable enabling of taking risks with not > updating files that possibly should be updated. > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > --=20 Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org --000000000000c1ed180634791702 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Mark,

Definitely I'm not getting the results I want wi= th WITH_META_MODE using BEs since most of the times I end up rebuilding alm= ost everything in new BE.

Should I stop using WITH_META_MODES a go straight to clean build= s (clean /usr/obj) instead?
My first concern is to spe= ed up builds expecially on rpi4.

Any hints are welcome.
Thanks,


Mark Millard <marklmi@yahoo.com> escreveu (segunda, 5/05/2= 025 =C3=A0(s) 23:18):
Nuno Teixeira <eduardo_at_freebsd.org> wrote on
Date: Mon, 05 May 2025 20:37:09 UTC :

> (...)
>
> Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not mes= s with
> ports and stuff.
>
> Nuno Teixeira <eduardo@freebsd.org> escreveu (segunda, 5/05/2025 =C3=A0(s)
> 21:34):
>
> > Hello,
> >
> > Using incremental WITH_META_MODE builds, after installation with<= br> > > beinstall.sh, building same src, a complete compilation happens.<= br> > >
> > If someone uses this script, could you please do the following te= st:
> >
> > WITH_META_MODE=3Dyes (/etc/src-env.conf)
> > filemon module loaded
> >
> > # cd /usr/src
> > # make buildworld-jobs buildkernel-jobs

The above used older commands and files from before
the following install. META_MODE recorded the use of
those commands.

Example .meta mode file content:

# Meta data file /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd= 64/lib/libc++/libc++.a.meta
CMD @echo building static c++ library
CMD @rm -f libc++.a
CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o charconv.= o chrono.o condition_variable.o condition_variable_destructor.o debug.o exc= eption.o filesystem/directory_iterator.o filesyste
m/int128_builtins.o filesystem/operations.o functional.o future.o hash.o io= s.o iostream.o locale.o memory.o mutex.o mutex_destructor.o new.o optional.= o random.o random_shuffle.o regex.o shared_mutex.o
stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o utility= .o valarray.o variant.o vector.o cxxrt_auxhelper.o cxxrt_dynamic_cast.o cxx= rt_exception.o cxxrt_guard.o cxxrt_libelftc_dem_g
nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o cxxrt_typeinfo.o CWD /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++=
TARGET libc++.a
-- command output --
building static c++ library

-- filemon acquired metadata --
# filemon version 5
# Target pid 22471
# Start 1611359217.214996
V 5
E 22961 /bin/sh
R 22961 /etc/libmap.conf
R 22961 /var/run/ld-elf.so.hints
R 22961 /lib/libedit.so.7
R 22961 /lib/libc.so.7
R 22961 /lib/libncursesw.so.9
R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE
F 22961 22962
E 22962 /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/le= gacy/usr/sbin/rm
R 22962 /etc/libmap.conf
R 22962 /var/run/ld-elf.so.hints
R 22962 /lib/libc.so.7
R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE
D 22962 libc++.a
X 22962 0 0
. . .

So META_MODE has lots of files that were used
that it can later detect being newer than the
prior build results, leading to rebuilds based
on those newer files.

> > # ./tools/build/beinstall.sh

The new be will have various updated files
that could be different by content and, for
commands, could behave differently than those
used to do the prior build. Detecting newer
time stamps on such used files leads to
rebuild activity.

More than /usr/src/ and /usr/obj/ content
are involved as well.

Note that the new be is based on somewhat
different files than the original
buildworld-jobs buildkernel-jobs was based
on.

> > # reboot
> >

(I presume booting into the new be here.)

> > # cd /usr/src
> > # make buildworld-jobs buildkernel-jobs

META_MODE will notice when commands are used
that are newer than when the prior build was
done. Similarly=C2=A0 for other files that may be
read. It will make sure that the newer commands
and files are allowed to produce new results
that potentially could be distinct in content
from what the old context produced for results.

> >
> > Since src and obj are the same from one BE to newer BE, minimal > > compilation should happen, not a full one.

META_MODE is more careful than that.

Note: I'm not claiming that new behavior that is
needed is likely for lots of the files with new
dates. But META_MODE is biased to avoiding leaving
in place something that should have been updated.

> >
> > Am I missing something here?
> >

Note that make has a -dM option:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0M=C2=A0 =C2=A0 =C2=A0 =C2= =A0Print debugging information about =E2=80=9Cmeta=E2=80=9D mode decisions<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0about targets.

So, for example,

file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/awk' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/cap_mkdb' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/cat' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/cp' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/crunchgen' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/crunchide' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/dd' is newer than the target...
. . .

Various . . ./tmp/legacy/. . ./*bin/ actually were
links to files.

Ultimately buildworld then installworld lead to new
dates for a bunch of files used. Later use of
META_MODE notices such and rebuilds based on the
newer files. (It is a lot of detail to go through
it all.)

Back in 2021 and 2023 I got help with exploring
avoiding lots of these. But, in the end, it
involved use of experimental code in
share/mk/src.sys.obj.mk to provide a new
definition to use to build some paths with.

The experiments were an unsupported activity that
produced an unsupported change to allow
configurable enabling of taking risks with not
updating files that possibly should be updated.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com



--
Nuno Teixeira
=
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org
--000000000000c1ed180634791702--