Do not clean (in buildworld/buildkernel) by default

[emaste]

Summary

As discussed on the freebsd-arch mailing list[1].  For historical
reasons FreeBSD's buildworld and buildkernel targets started by cleaning
the object tree, for traditional (non-metamode) builds.

Cleaning is not necessary when dependencies are properly tracked, and we
have a somewhat kludgey script[2] to handle some known cases where deps
were mishandled.  Be consistent with the vast majority of open source
build systems by default, and do not clean at the beginning of
buildworld or buildkernel.

Users may set WITH_CLEAN in src.conf(5) to restore the previous
behaviour, or run `make cleanworld` and/or `make cleankernel` before
starting a build.

[1] https://lists.freebsd.org/archives/freebsd-arch/2024-July/000727.html
[2] tools/build/depend-cleanup.sh

[imp]

Did we ever decide on developer guidance on the look back period?

[emaste]

In D46172#1052448, @imp wrote:

Did we ever decide on developer guidance on the look back period?

In tools/build/depend-cleanup.sh we have:

# Our current make(1)-based approach to dependency tracking cannot cope with
# certain source tree changes, including:
# - removing source files
# - replacing generated files with files committed to the tree
# - changing file extensions (e.g. a C source file rewritten in C++)
#
# We handle those cases here in an ad-hoc fashion by looking for the known-
# bad case in the main .depend file, and if found deleting all of the related
# .depend files (including for example the lib32 version).
#
# These tests increase the build time (albeit by a small amount), so they
# should be removed once enough time has passed and it is extremely unlikely
# anyone would try a NO_CLEAN build against an object tree from before the
# related change.  One year should be sufficient.

of course we have entries much older than that - the first one is:

# 20200310  r358851  rename of openmp's ittnotify_static.c to .cpp
clean_dep lib/libomp ittnotify_static c

I'll make a pass to clean up old ones.

[emaste]

I'll make a pass to clean up old ones.

D46178

[imp]

In D46172#1052545, @emaste wrote:

In D46172#1052448, @imp wrote:

Did we ever decide on developer guidance on the look back period?

In tools/build/depend-cleanup.sh we have:

# Our current make(1)-based approach to dependency tracking cannot cope with
# certain source tree changes, including:
# - removing source files
# - replacing generated files with files committed to the tree
# - changing file extensions (e.g. a C source file rewritten in C++)
#
# We handle those cases here in an ad-hoc fashion by looking for the known-
# bad case in the main .depend file, and if found deleting all of the related
# .depend files (including for example the lib32 version).
#
# These tests increase the build time (albeit by a small amount), so they
# should be removed once enough time has passed and it is extremely unlikely
# anyone would try a NO_CLEAN build against an object tree from before the
# related change.  One year should be sufficient.

of course we have entries much older than that - the first one is:

# 20200310  r358851  rename of openmp's ittnotify_static.c to .cpp
clean_dep lib/libomp ittnotify_static c

I'll make a pass to clean up old ones.

So it should be << ~2.5 years, our average major branch to branch time.
1 year is likely too long... We update clang every 3-4 months and there's no benefit to an incremental build across that event.
6 months might be better, but that might be a smidge short since it will produce an error in the build for people that don't update their systems often enough.

But killing the stuff back older than 2022 is certainly no brainer yes :)