Re: Default NO_CLEAN=yes in 15+

On Tue, 23 Jul 2024 at 16:08, Shawn Webb <shawn.webb@hardenedbsd.org> wrote:
>
> 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.

Issues do arise on occasion, and there are some known deficiencies in
our standard infrastructure with respect to dependencies. Have a look
at tools/build/depend-cleanup.sh for some special cases to handle
no-clean builds. We need to get better at making sure these are
consistently added for new cases. Our assumption should be that
non-clean builds are generally expected to work, on an ongoing basis.
There may be rare cases where it is too awkward to add a special case.
If that happens we should just have the build perform a full clean if
we can detect the failing condition, or give a heads-up on mailing
lists that a clean build will be required.

We need to guarantee that release artifacts aren't affected by
incremental build contamination, of course -- but that is (needs to
be) done by the release build process starting with a fresh checkout,
rather than relying on a clean step built into the default target.

If you do run into a problem with an incremental build please follow
up on the mailing list (or in a PR) so that it can be added to the
special case script.