From nobody Tue Jul 23 20:03:52 2024 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WT7QF5FHNz5QJv9 for ; Tue, 23 Jul 2024 20:04:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT7QF3Wzsz48j1 for ; Tue, 23 Jul 2024 20:04:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x132.google.com with SMTP id e9e14a558f8ab-39834949f27so20612255ab.2 for ; Tue, 23 Jul 2024 13:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721765044; x=1722369844; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=z5+iwfJ99+ZJ1yp0xXbv2r9MaISTEvv4LEPdVSAlL7U=; b=eJHiAE1+BrLfUSYxzN5twHYRm/fZ+OVmQKXkflbopKrAvxcylnoRTD4Usqt6HcGuGM HtuDLp1qiYr4rSJ7+JP9xcJKYJ456FlGEXQ3qTsmtDBIC1TZI426xhfQG8bTbOrCqRT/ 0B0d0RWxnZDDkVsGDNOrIJ6uGEvIA/qtLMi9VootJF1IFG4+PH0SrayuFoodlvMb4JSs 1Kje+8jKVaCliv/yUlx0Mmj0i9jcgI2Fd+OgNkmdUNDBlDd81rVAlEVCjJdLQ7jZSCN5 vUP3rz388X0AwCDdztY5cqsLJl3ZWpcNFTJuWoXmFqlYZqgerdunzHxq/uUHrMgHB94i ibWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721765044; x=1722369844; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=z5+iwfJ99+ZJ1yp0xXbv2r9MaISTEvv4LEPdVSAlL7U=; b=W6CLVu29XT+DXNzADe7k/3nr2qnaZRpm7Aa1u988c6WqMSU/B8SoxplswEwAixXyqT ByXxV1ILc1ZqqD0zkhkRfJLqclPgY+43r/0yIL2+irkbBvwbqaAf3f4X7b5ljijHy5aq XO9E3e1xjktRlw/likAt16D58IghFhrh5uzoqaLHMSTdYaDXXGBJwEBG54zf9k3QWRDy uMuL8hz9Fs6S99krUrZAUUqqeX6/q0wyScvKhVLOXbGcnK98+SGPIiCHi2nCKXPpvSGK TxBexv9a+b2FRas1/oFZ4ZBzhSgiUiC4LfQdVh9qsS6i402q329PbGNT8uYr9MU6Y9wK fm1g== X-Gm-Message-State: AOJu0YyaPhTF6hEgRN2wZgdhs/rYEwsNvHyInnKdbyGhN7uqAyo/wX4f uN5l0jSYBJ/kvbN3FkVCeXP96o1jrEOQV07yg6rU3B+7IkewNkhg31+sqQmMd4/RE5mNOPlcFmX kk8WR9wZIdR/IWUpJCzcWjrs1LI9vV7p7GDG12Q== X-Google-Smtp-Source: AGHT+IFER5zY7twGMVE2hsv1bFo/6+zCKB48aZWim2Zm0VTJ7iw46nPc8qkVv30rUrShnu3qUktZYUQbVR7lPeIlnjc= X-Received: by 2002:a92:c243:0:b0:398:1bf7:a177 with SMTP id e9e14a558f8ab-39a1925327fmr615195ab.5.1721765044530; Tue, 23 Jul 2024 13:04:04 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> In-Reply-To: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> From: Warner Losh Date: Tue, 23 Jul 2024 14:03:52 -0600 Message-ID: Subject: Re: Default NO_CLEAN=yes in 15+ To: John Baldwin Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000ddd003061defa9a1" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WT7QF3Wzsz48j1 --000000000000ddd003061defa9a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 23, 2024, 1:58=E2=80=AFPM 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 s= ee > how far back it goes). To permit incremental builds, this step can be > skipped > via NO_CLEAN=3Dyes. 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 dedicate= d > clean targets as well (cleanworld and cleankernel). For myself, I always > use NO_CLEAN=3Dyes when building worlds and kernels. If I need a clean b= uild > 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=3Dyes. To > preserve > existing behavior this knob currently defaults to on, but I know Ed's goa= l > 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=3Dyes if our docs do not do this > already. > +1 On the one condition that NO_CLEAN will be silently ignored after... Warner > -- > John Baldwin > > --000000000000ddd003061defa9a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 23, 2024, 1:58=E2=80=AFPM John Baldwin <= ;jhb@freebsd.org> wrote:
The buildworld and buildkernel targets incl= ude a "clean" step before building
objects dating back before my time to 'make world' (I haven't l= ooked to see
how far back it goes).=C2=A0 To permit incremental builds, this step can be= skipped
via NO_CLEAN=3Dyes.=C2=A0 This step is a bit unusual in build systems howev= er.=C2=A0 Most
build systems have separate commands for building vs cleaning (e.g. 'ma= ke all'
vs 'make clean') and over time FreeBSD's build system has gaine= d dedicated
clean targets as well (cleanworld and cleankernel).=C2=A0 For myself, I alw= ays
use NO_CLEAN=3Dyes when building worlds and kernels.=C2=A0 If I need a clea= n build
I use the dedicated clean targets (e.g. cleanworld) first.=C2=A0 In particu= lar,
cleanworld/cleankernel are far more efficient since they use a single
recursive 'rm' whereas the "clean" step involves a full t= ree 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=3Dyes.= =C2=A0 To preserve
existing behavior this knob currently defaults to on, but I know Ed's g= oal
was to eventually flip the default so that NO_CLEAN builds would be the
default.=C2=A0 I would like us to do that starting in 15.

Further off, I would suggest that we remove the "clean" step outr= ight,
perhaps in 16.x.=C2=A0 Regardless, we will need to update documentation to<= br> prefer the clean targets over WITH_CLEAN=3Dyes if our docs do not do this already.

+1

On the one = condition that NO_CLEAN will be silently ignored after...

Warner
--
John Baldwin

--000000000000ddd003061defa9a1--