Re: /usr/sbin/etcupdate -D/usr/obj/DESTDIRs/main-CA7-chroot -s /usr/main-src -M TARGET_ARCH=armv7 ends up building dtc !

On Aug 13, 2023, at 12:07, Jessica Clarke <jrtc27@freebsd.org> wrote:

> On Sun, Aug 13, 2023 at 02:23:54AM -0700, Mark Millard wrote:
>> On Aug 13, 2023, at 01:06, Mina Galić <freebsd@igalic.co> wrote:
>> 
>>> from IRC, i have learned this is working as designed:
>>> etcupdate without -B does a build.
>> 
>> My interpretation of what "build" referred to for
>> etcupate was way off. I've added the -B's that I
>> was not using before.
>> 
>> Thanks for the note!
>> 
>>> Also, jrtc27 recently made it so bootstrapping, because otherwise BUILD_WITH_STRICT_TMPPATH doesn't work: https://github.com/freebsd/freebsd-src/commit/d81da4c98328d4ee3fe4c0a85f6874a3c69a1afd
>> 
>> Yep: that added what leads to the dtc build.
>> 
>> I still wonder if etcupdate builds more than it needs to
>> for its specific pruposes when it does do a build:
>> building dtc in order to complete an etcupdate just seems
>> time/resource wasting.
> 
> It does, but teasing apart what's needed for buildworld/buildkernel and
> just buildetc is a bunch of work, and better to have something that
> works inefficiently than something that doesn't work. Patches more than
> welcome to make it more efficient. However, I will note that 99% of the
> time -B is what people should be using, so it's not all that important
> (it's rare that you want to produce an etcupdate tree from sources that
> haven't just been built).

Thanks for the note.

-B is not the default for etcupdate. Because of that, it would probably
help if the various places that document using etcupdate for the 99%
type of context had an explicit "normally use -B despite it not being
a default" and "omit -B only when the source tree version has not been
built yet". Such might be easier to follow than just the existing
wording. Although, the lack of -B for diff, resolve, revert, and
status is messy. If those silently ignored when -B , the instructions
for use of -B could be simpler.

===
Mark Millard
marklmi at yahoo.com