From nobody Tue Jul 23 20:37:08 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 4WT88f52xCz5QMxg for ; Tue, 23 Jul 2024 20:37:22 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (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 4WT88d5rlKz4Kck; Tue, 23 Jul 2024 20:37:21 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-f44.google.com with SMTP id ca18e2360f4ac-819c1f5348aso213466839f.0; Tue, 23 Jul 2024 13:37:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721767040; x=1722371840; 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=XN2ye7hpq9PfkA4IrzyjqUHzrA6GrnKuOup8jF5ZZ/0=; b=upyBCzZRoFChK2upOwvhEYIDzfSJgqomPELZdnb2MRO0+a06FZELh2QY0SV+g9Rp51 QCdfFvAO9dmTLakz9c41vWM9zW9Mj75dy0LUHGYuYcqxW2PhYhv5/Y4IghmGZTAIuzh6 98Ao/RmbIaaI57rfWklzGAP/4RIAJR8G5LR5cKXNGVtF7y8I1IA4O7TDPBZjJuSn/IPp NITzq07SxUagWjEe44P1c8N/27YqvC5JOS0ArnWt+D4u+CHeW2N9s5c6OSocxECjEqVG siEUX40N9V6In6wR1+NJDzPRMZmNrLujlZ0jRIddNihxkp/v0UqrxXSeXFPamg9Aovo/ c3FQ== X-Forwarded-Encrypted: i=1; AJvYcCUEWJPrw/qaDLopzyv+4SgtRTkdPmLgkqNIt/k9tAtLYuaBVUULU/qaXJ2oBg+7POCcjGUAkAQxma3xMGIVz5MV X-Gm-Message-State: AOJu0YxdEeqExPJKlpvdi02zMkoywNVjKsK0lN7rVR+a/G2ON/dC+Mix SpIOXklPrOYbIuie34r0ryX90qZ+5Nhdj+Z7/ZVb0ILjrylAjUCmfoGrzp0eDr4vLBxyuL77UNg 2B9GiFYzK622jNbZL5yyjvKuC8zikEMPp X-Google-Smtp-Source: AGHT+IEGco1Ex6lawunqCanOAC2IUskdbwuhF99YoSW5P+YanXN1xHqJ+NUkJCFDSlbVf0+zsLzucQqvVBAWe/GSUgo= X-Received: by 2002:a05:6602:2b09:b0:7fc:923f:255b with SMTP id ca18e2360f4ac-81f71da0188mr28621239f.16.1721767040058; Tue, 23 Jul 2024 13:37:20 -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: From: Ed Maste Date: Tue, 23 Jul 2024 16:37:08 -0400 Message-ID: Subject: Re: Default NO_CLEAN=yes in 15+ To: Shawn Webb Cc: John Baldwin , arch@freebsd.org Content-Type: text/plain; charset="UTF-8" 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:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4WT88d5rlKz4Kck On Tue, 23 Jul 2024 at 16:08, Shawn Webb wrote: > > It would make sense to me to default MK_CLEAN=no in release branches. > Perhaps stable branches, too. While I don't hold a strong opinion on > the matter, I would prefer MK_CLEAN=yes to remain the default on the > main branch. > > I can't give tangible examples, but I remember running into weird > issues occasionally when using `make buildworld WITHOUT_CLEAN=yes` in > main. I probably should do a better job at documenting those > (infrequent) issues when they arise. Issues do arise on occasion, and there are some known deficiencies in our standard infrastructure with respect to dependencies. Have a look at tools/build/depend-cleanup.sh for some special cases to handle no-clean builds. We need to get better at making sure these are consistently added for new cases. Our assumption should be that non-clean builds are generally expected to work, on an ongoing basis. There may be rare cases where it is too awkward to add a special case. If that happens we should just have the build perform a full clean if we can detect the failing condition, or give a heads-up on mailing lists that a clean build will be required. We need to guarantee that release artifacts aren't affected by incremental build contamination, of course -- but that is (needs to be) done by the release build process starting with a fresh checkout, rather than relying on a clean step built into the default target. If you do run into a problem with an incremental build please follow up on the mailing list (or in a PR) so that it can be added to the special case script.