Re: Default NO_CLEAN=yes in 15+

Tomek CEDRO <[email protected]>
Newsgroups gmane.os.freebsd.architechture
Message-ID <CAFYkXj=fLSg2p99gPkWM2aZuiwdhy7NMm7E5=yO0Fdq6sTzOSQ@mail.gmail.com>
On Tue, Jul 23, 2024 at 9:58 PM John Baldwin <[email protected]> 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.
>
> Further off, I would suggest that we remove the "clean" step outright,
> perhaps in 16.x.  Regardless, we will need to update documentation to
> prefer the clean targets over WITH_CLEAN=yes if our docs do not do this
> already.
>
> --
> John Baldwin

+1 :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
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.