From nobody Tue Jul 23 19:58:13 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 4WT7HV44WKz5QJgP for ; Tue, 23 Jul 2024 19:58:14 +0000 (UTC) (envelope-from jhb@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 4WT7HV3GGKz476f for ; Tue, 23 Jul 2024 19:58:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721764694; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ILnigj07bQFH2MZxpFb0aCMfHaK2T4up+dsXo06Sg5s=; b=yz5qISMgy/XGFaqfySo7CJ5QZZjrau2buh8IxzJHoeniGRGY8Xf4EVlWqsa+yhGJ8fjcVh OCDUPmD2VXciZhXc/tLVvuPfZPsW6x7Sz9kk7kyJrNoKuLW/9yXPv1NNK1Grzk7TVhwH+f 0ohFsf25mRnp83RPAoKVVzHo6ZWOc8DDYn9z3bdXqJ8CAaHPk6ZB55o7OZrIbEFbMScIOI iHaAUBB4o1d0leq42nRN6s4VIPoR835Y54lgMsudv22GYw8tkMorQIG9FdnddaSzf5513e frvjMSCI9Bn5a5PRroTPgxU3E308Lpv18HUcfOcpF75UwJUCsdZ3OS+wKl2XUw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721764694; a=rsa-sha256; cv=none; b=Q3s8rUlKoToBGYElXKIIp9KPCzJ8sniN2jUWjzYAuFlcjZpkLqWa1BPxt8srcwTPHI2haZ 0yGI8OH/fmiAR9HIZm/jOLs9hp/0qJLw+rBbLlVjFjdNzLvbZOQABKn4G9lMoyeUFEnMWs YlT2nHiBhVU9bpSHSVNpv+Xo0XlMUVg23NXw7CwuKVVRW1QER+eZlYHdJjZE4FWdR1cSpX SBnuqoj1fv64owvvW4S7GY/o/MhEWx92Ep1liycHpLAW2Bj2sgUoORDmktai3frdWxCQNg byBInVuTUTV8QC3Kiz4pzOG/V6uDcTN28UmxzsZ2wQ76YvqViENEMCHcAtawiQ== 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=1721764694; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ILnigj07bQFH2MZxpFb0aCMfHaK2T4up+dsXo06Sg5s=; b=pganxC2Ju0G02ISKeojNLhq5XTqkOfYK/n7gJNBGWB2I4/LnpcTthac4OeA/ujkvsbQjxP NN+tBvxjfGdIFFNtEmyJ+HH9Kb/Tim5dPvcOwtTapRiM8pnbX3RA+k9Kkq6O567Mxu8s4H mmCn7RsMvDy7+FDgGNppnOm/2tj6kUE0bYfBuAef+gPSEO1zAGBXRy6KUXekJ0sKIhPPBL 6MsvPL1pBhxpRhSSYCniGIVIl0oWAVQjvvhrPdpDpZ9kSQFJY2ap6k0bJrYRGRkcZbU/JB VtlTx0HT9quF5lZc+XwBoC3gAwlb6u29WWsfXrRRxHQ7R/45WIC8AoZCNuvPow== Received: from [IPV6:2601:5c0:4200:b830:1c6f:3b0e:485e:1a76] (unknown [IPv6:2601:5c0:4200:b830:1c6f:3b0e:485e:1a76]) (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 did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WT7HV2CDZzFNK for ; Tue, 23 Jul 2024 19:58:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> Date: Tue, 23 Jul 2024 15:58:13 -0400 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 User-Agent: Mozilla Thunderbird Content-Language: en-US From: John Baldwin To: arch@FreeBSD.org Subject: Default NO_CLEAN=yes in 15+ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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