From nobody Tue Jul 23 20:33:28 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 4WT84B0WZcz5QN27 for ; Tue, 23 Jul 2024 20:33:30 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT84975Mqz4KXM; Tue, 23 Jul 2024 20:33:29 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721766810; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qcPzhCQPmIicoLqsJVVFwI0KuYCWGBvcVAOwefwLe48=; b=LMHAVoShSFgOSySDqQVt59PFto2zWqnhA+/D3cWUzfsbTwPkwfkMyi74V6jKXaZ5UzZclm icvuxSEqidCpCkh8DP6UbAxO8OqJLdnLj8N6wTILfQSGDr9FHu0A3XmZQDIb1uJSJoD+/J Uyn7BcaAthHXORT7qh7gR3Z+01UThHgrdO3eb2zKE7IQj7lWQwbmwP6SGSVIsxmGUx8kn9 VYh8yW+J4BJCIcJYDBVmvt+cj3AaXiXKxKqclWLnI+eFmOJNCqmvN8M4yeysyZ+WN/oJwu QH4RCINOId+7Jk4FAnI14z+1EEvAZzmGJtJ11HyboucdmY8CitkcqYK3Oc+1mg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721766810; a=rsa-sha256; cv=none; b=pRwo+WTz515RLhWOnU0c2s5RBXqlaH24LyUYkYJ1sDS+2kpGJCXxPkLTSvb60+2GGyYSw9 gWP9nCZlO62tjX7gQ4gaznbLOhgw9GrcYKIMiFSsBXAz9a64c3gaQek3jeHbOfbTH6Hw1+ cz4dLTwyx8rC87dVPHnqWGGpTiB/yCLqNe98m05Q9U2qOAXnjxijfOUvdcaFK6UaGqkExr czfZ+++3X/qsTSkImlVOozrJwohhlhBs4GOj1Of2vweyvRsejnH+eWOmjiBw7LVMz0TgFD 4GDD2kL7D1SS2tRnmURC8xppw0wvdPi9eV11NJfYJP+b5wq6w5Bh3BVEDpnz5g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721766810; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qcPzhCQPmIicoLqsJVVFwI0KuYCWGBvcVAOwefwLe48=; b=yR2i4lZ9SadQKFAAShMKBOvrucXrK1PuzFbYBCmMuP5NNji8aYPLL33kkPbK3cYojFe+dQ fqj6+e+q3ZKjPMphw40lrgNHcm+q7hKXcV3k7Zbqh9eNlfnaMvJHTeGobmeNIQWZYScV94 IoSKY3ilxiKpRF7ihw1Xr+sBl31FKTEsDJYi5Ic7Asydwt4iRJEXDyHDyD9s0C9FmuV6UZ hH8PkZrjMf/WF2vkGuSSYir0lA83GDhizppSok/pyTuLjXiqD7Jei9rf8g42bhPH9NXKDS dhBDQLGywh365XqcskQw1ibNsHmjaygcwwkE8JrRuKzoFyDCea/BddEJrej5cw== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WT8496R8czGf8; Tue, 23 Jul 2024 20:33:29 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id C4A943C019B; Tue, 23 Jul 2024 20:33:28 +0000 (UTC) Date: Tue, 23 Jul 2024 20:33:28 +0000 From: Brooks Davis To: John Baldwin Cc: arch@freebsd.org Subject: Re: Default NO_CLEAN=yes in 15+ Message-ID: References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> On Tue, Jul 23, 2024 at 03:58:13PM -0400, 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 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. +1 We should continue spot cleanups for things like foo.c -> foo.S as required rather than pointlessly rebuilding everything every time. It's much better for a small number of people to spend time tidying things up than to make expensive cleaning the default. > 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. I strongly agree. It's all weird and unnecessary with things like git-clean(1) available. Eventually I'd like to get rid of cleandir and its weird behavior differences based on .OBJDIR's existence. This is tooling for the distant past. -- Brooks