Re: Default NO_CLEAN=yes in 15+

Ed Maste <[email protected]>
Newsgroups gmane.os.freebsd.architechture
Message-ID <CAPyFy2Anks1CKOxJ-gWAtVHWRW6TyKYmn7hAAQmO=X+euhkUsA@mail.gmail.com>
On Tue, 23 Jul 2024 at 16:08, Shawn Webb <[email protected]> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.