From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id F3BEC1F66F for ; Thu, 5 Nov 2020 21:48:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732383AbgKEVsc (ORCPT ); Thu, 5 Nov 2020 16:48:32 -0500 Received: from pb-smtp1.pobox.com ([64.147.108.70]:53096 "EHLO pb-smtp1.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731508AbgKEVsc (ORCPT ); Thu, 5 Nov 2020 16:48:32 -0500 Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 73A0E9167B; Thu, 5 Nov 2020 16:48:30 -0500 (EST) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=ub49GpARSvF4B1GIrwCxvPyEh5g=; b=m82G5d T7JUZSEcUtdDwSmf5oHXj9qYkGfpWFG75MulxI8reVaraKdsX0NM3iR65X2TvqFJ JSGNVXn9fS42ccZ454osJ28BZSn/7sqWE8miBFT98t4OgoYcxpAFqLLq3jbGD55U 0KDLnSEuVS/5VcPalRcdCXpgsVIclieoJKhx4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=XlA0FYqcYPjlFBMbsGz6FILMUdEnY2r/ 2uQWU8hGxg1F0d1OJobwzpj7nVP8c2dAxLIYivbqdDsIRgIUj5FLbJS2k4hX/mBM re7g72L3rXZHXsdbkx0OK9cYC3z/Vpcq9iS5q3AKMXPrD8wqi9FyuK4hj6qAzEsy x0tAl1301ak= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 6BAB39167A; Thu, 5 Nov 2020 16:48:30 -0500 (EST) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.74.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id ED88B91677; Thu, 5 Nov 2020 16:48:29 -0500 (EST) (envelope-from junio@pobox.com) From: Junio C Hamano To: Ramsay Jones Cc: GIT Mailing-list , Pratyush Yadav , Adam Dinwoodie Subject: Re: [RFC PATCH 0/8] speed up 'make clean' References: Date: Thu, 05 Nov 2020 13:48:29 -0800 In-Reply-To: (Ramsay Jones's message of "Thu, 5 Nov 2020 21:01:08 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: A4861850-1FB0-11EB-BCAF-D152C8D8090B-77302942!pb-smtp1.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Ramsay Jones writes: > [Yes, 'cd Documentation; make clean all' will be slower that a doing > separate 'make clean; make', but the extra 10s, or so, will be swamped > by the documentation build time! ;-) ] Hmph, the "all" part in "make clean all" needs the information we read from these generated files, and time must be spent to generate them whether "make clean all" or "make clean; make all" is used. In the latter, we may not generate and read them in the first phase, but the second one "make all" would need to do so anyway. So I am puzzled why "make clean all" needs to be slower---don't we generate and read them only once in either case?