Re: Default NO_CLEAN=yes in 15+

On Wed, Jul 24, 2024, 8:33 AM Bjoern A. Zeeb <bz@freebsd.org> wrote:

> On Tue, 23 Jul 2024, John Baldwin wrote:
>
> > On 7/23/24 16:08, Shawn Webb wrote:
> >> On Tue, Jul 23, 2024 at 03:58:13PM -0400, John Baldwin wrote:
> >>> The buildworld and buildkernel targets include a "clean" step before
> >>> building
> >>> objects dating back before my time to 'make world' (I haven't looked
> to
> >>> see
> >>> how far back it goes).  To permit incremental builds, this step can be
> >>> skipped
> >>> via NO_CLEAN=yes.  This step is a bit unusual in build systems
> however.
> >>> Most
> >>> build systems have separate commands for building vs cleaning (e.g.
> 'make
> >>> all'
> >>> vs 'make clean') and over time FreeBSD's build system has gained
> dedicated
> >>> clean targets as well (cleanworld and cleankernel).  For myself, I
> always
> >>> use NO_CLEAN=yes when building worlds and kernels.  If I need a clean
> >>> build
> >>> I use the dedicated clean targets (e.g. cleanworld) first.  In
> particular,
> >>> cleanworld/cleankernel are far more efficient since they use a single
> >>> recursive 'rm' whereas the "clean" step involves a full tree walk with
> >>> nested make invocations of the 'cleandir' target.
> >>>
> >>> A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to
> as a
> >>> WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=yes.  To
> >>> preserve
> >>> existing behavior this knob currently defaults to on, but I know Ed's
> goal
> >>> was to eventually flip the default so that NO_CLEAN builds would be the
> >>> default.  I would like us to do that starting in 15.
> >>
> >> It would make sense to me to default MK_CLEAN=no in release branches.
> >> Perhaps stable branches, too. While I don't hold a strong opinion on
> >> the matter, I would prefer MK_CLEAN=yes to remain the default on the
> >> main branch.
> >>
> >> I can't give tangible examples, but I remember running into weird
> >> issues occasionally when using `make buildworld WITHOUT_CLEAN=yes` in
> >> main. I probably should do a better job at documenting those
> >> (infrequent) issues when they arise.
> >
> > To be clear, the suggestion is that when you hit an issue, just run
> > 'make cleanworld' rather than relying on the omission of NO_CLEAN=yes
> > to do this for you (and much slower at that).  Have you used any other
> > build systems where 'make' does an implicit 'make clean' before it
> > builds?  I have never encountered another where this is true.  'clean' is
> > always a separate target from 'all' in my experience.
>
> Can we (if not in 15 but then in 16) simply:
>
> (1) document clean builds as make cleanblah .. && make blah
> (2) document that if we do not run make cleanblah we'll get an
>      incremental build
> (3) if an incremental build fails (CI will detect as well) -- do as Ed
>      said
>

No. It won't. Or only sometimes. I've had several times when tree A builds
just fine whole tree B won't. 90% of the time it is an accumulation of
changes that cause B (the older) to fail. The rest of the time it's build
settings differences. We can get a lot of it from CI, but we will miss
about 10% or so of the issues.

There's maybe one breakage in 20 or 30 that will be some kind of judgement
call, so we likely should establish sone guidance. Like how old is too old?
On current, this is likely 6-9 months. On stable it's likely the branch
point for the oldest supported release on the branch (also 6-9 months),
though a good case could be made for one additional release prior since the
cost is likely small, though the testing logistics get complicated.

Likewise for build options.

And for everything there's always a "too hard" reset available,  though
maybe that should be decided with the forthcoming srcmgr of current and
maybe with re too for stable.


(4) make sure re and so are aware of the extra make cleanblah needed?
>

They already start with an empty /usr/obj.

(5) remove NO_CLEAN and MK_CLEAN entirely (there's no point in flipping
>      the default if you can choose to run a make step or not)?
>
> I think that is basically your suggestion?
>

Basically, yes.

Warner

+101 for that from here.
>
> /bz
>
> --
> Bjoern A. Zeeb                                                     r15:7
>
>