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 00B301FA04 for ; Tue, 12 May 2020 21:03:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731241AbgELVDZ (ORCPT ); Tue, 12 May 2020 17:03:25 -0400 Received: from pb-smtp20.pobox.com ([173.228.157.52]:59332 "EHLO pb-smtp20.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725938AbgELVDZ (ORCPT ); Tue, 12 May 2020 17:03:25 -0400 Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 5B199D3E9C; Tue, 12 May 2020 17:03:23 -0400 (EDT) (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=G1fWOlajSVvxWDA0J/DZD8QwxSw=; b=wFCr7U zLZ0kUtkPQa0LKPjkfJX5MhELmaA9gL2bgKD+wrPditU1l7/DjQAD9ESJOXExKgf jsRAAf0UyuP/Yz+BVJJjwZ3nmLdqgs8WqcfmaQ20sy1QNMDNmc6hris3ewC/34G8 T3RUvpR84CqrWTzyVnC0/os33xo7nxKQYetPI= 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=CjJHnlQNd0oB7e4ah33SaC65Cq13q+Vi 2IHIUOzEwBE8Kx9FGLSSO/jy2UNcBNtNffL4CITjuLxluZjvvNPmXEz7HNU2idJ3 THE+0nUjlstSFe3bCuBmq8pI8DHipj+BKDShSprC4kXUZ93wGid8wzgTtQqByKH5 QMM+J0zegyM= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 54931D3E9B; Tue, 12 May 2020 17:03:23 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.74.99.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 90603D3E9A; Tue, 12 May 2020 17:03:20 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: "Sibi Siddharthan via GitGitGadget" Cc: git@vger.kernel.org, Sibi Siddharthan Subject: Re: [PATCH v2 10/11] cmake: parse the makefile for the sources. References: Date: Tue, 12 May 2020 14:03:18 -0700 In-Reply-To: (Sibi Siddharthan via GitGitGadget's message of "Tue, 12 May 2020 16:50:53 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 027D7924-9494-11EA-A296-B0405B776F7B-77302942!pb-smtp20.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org "Sibi Siddharthan via GitGitGadget" writes: > From: Sibi Siddharthan > > The CMake script parses the Makefile for: > SCRIPT_SH > SCRIPT_PERL > TEST_BUILTINS_OBJS > LIB_OBJS > BUILTIN_OBJS > XDIFF_OBJS > VCSSVN_OBJS > > By doing this we avoid duplication of text between the Makefile and > the CMake script. Thanks, this makes perfect sense, but it probably should have been done from the very beginning, without copying the huge list manually in the step [01/11]. How robust is the "parser"? Do we need to leave an instruction to Makefile writers to conform to certain style to help CMake users as an additional comment in the Makefile, or is any reasonable textual drift still accepted?