From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 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,RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 7C6DE20954 for ; Mon, 27 Nov 2017 09:08:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751313AbdK0JIU (ORCPT ); Mon, 27 Nov 2017 04:08:20 -0500 Received: from pb-smtp2.pobox.com ([64.147.108.71]:64371 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751141AbdK0JIS (ORCPT ); Mon, 27 Nov 2017 04:08:18 -0500 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 0A667BE0E3; Mon, 27 Nov 2017 04:08:18 -0500 (EST) 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=zXLc8uOg2ouOUcQ9sxWg75IuZaQ=; b=jWD4H1 xSx7tRrnZHenKSzdQnXGrZbXTTNVUmYn9G85v+s5ZowhCvbzWM2KANPmLrdHwu7A 0X31HsV8hTOo3bfckhEXr/LC5x+jCzCUxlKuOQGsi5i4afv2lpWtcQ9Y8bV05qLH TdR0+tMcWcmzT2n9QmeYrmb7D1mKoF782400o= 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=kGecIwe7sxc9K7Q0T52UE1RLQpYFvH0u y2N9e1cRte5YvKBbcW1IkbzRGoVcz/W9SMlWPcL4/eZIIqpvUv5LLGuhnvPBFKt5 3FPXDTSskBF+QH8sSNoYKJQ/e7WzdOriPrAUre+sjqN3CbVFFSN9Jxx/72J5/Z3a YllXow/v/tc= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 01D2CBE0E2; Mon, 27 Nov 2017 04:08:18 -0500 (EST) Received: from pobox.com (unknown [104.132.0.95]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 540F6BE0E1; Mon, 27 Nov 2017 04:08:17 -0500 (EST) From: Junio C Hamano To: Jeff King Cc: Christian Couder , Jonathan Nieder , git , Dominik Mahrer , git-packagers@googlegroups.com, Todd Zullinger , Christian Couder Subject: Re: [PATCH] Makefile: check that tcl/tk is installed References: <20171120171517.6365-1-chriscool@tuxfamily.org> <20171120191931.okxejqyqayjvxpbc@aiede.mtv.corp.google.com> <20171126191510.GA1501@sigill> <20171127043502.GA5946@sigill> Date: Mon, 27 Nov 2017 18:08:16 +0900 In-Reply-To: <20171127043502.GA5946@sigill> (Jeff King's message of "Sun, 26 Nov 2017 23:35:02 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 81A9438C-D352-11E7-A2FC-575F0C78B957-77302942!pb-smtp2.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Jeff King writes: > I think that's the rub, though. We hit this code path by default, so > it's _not_ a sign that the builder cares about gitk. OK. >> Whether the builder wants to run the result on the same box is a >> separate and irrelevant matter. Once built and installed, a box >> without "wish" may not be able to run the result, but installing it >> after the fact will fix it without need to rebuild anything. > > Yeah, this side-steps the "other half" of the issue that Christian's > patch addresses, which seems like the more controversial part (I don't > have a strong opinion myself, though). Is that controversial at all? In the sense that it is addressing a non-issue (i.e. it is perfectly fine if installed gitk fails at runtime complaining that it cannot find wish), it might be, but to me, it appears there isn't any room for controversy there. But an out-of-box build that fails _is_ a problem worth addressing to, so I view it primarily as the "how do we do msgfmt (or its substitute that is good enough for tcl script)" issue. Perhaps we can export NO_GETTEXT from the top-level Makefile and have Makefiles in these two subdirectories to pay attention to it, in addition to NO_MSGFMT, and build them without i18n support instead of failing, or something?