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.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,T_DKIM_INVALID, T_RP_MATCHES_RCVD shortcircuit=no autolearn=no 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 F2A831F404 for ; Fri, 19 Jan 2018 18:41:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756162AbeASSld (ORCPT ); Fri, 19 Jan 2018 13:41:33 -0500 Received: from imap.thunk.org ([74.207.234.97]:38870 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755830AbeASSlb (ORCPT ); Fri, 19 Jan 2018 13:41:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Q41ZZNaUoq05hVW6ZMMAcX8l8ziSJFd2AEMYgO62Nm8=; b=OZNFYo9pn7uhl/xfymMxPqIJZu Irsdgd8Qw7i6n+XPkdIjL0TcOwt1mFqRmheKgtuOWnwzg3ziZFX055CXJyjzuP4dy1uXahZFvIWzj mTgMHRuJtOseDAcJwwDw8UCIYEDGlapWSq+pYm2K5mN3+4X06tCQF4HvObMS/tzIMtEU=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1ecbbV-0007Sd-G6; Fri, 19 Jan 2018 18:41:29 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id A3C96C003D5; Fri, 19 Jan 2018 13:41:28 -0500 (EST) Date: Fri, 19 Jan 2018 13:41:28 -0500 From: Theodore Ts'o To: "Robert P. J. Day" Cc: Git Mailing list Subject: Re: should any build system legitimately change any tracked files? Message-ID: <20180119184128.GA643@thunk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Fri, Jan 19, 2018 at 12:51:52PM -0500, Robert P. J. Day wrote: > that's all the info i was given, but it *seems* clear that the build > process itself was making changes to one or more tracked files. > > technically, i guess one can design a build system to do pretty > much anything, but is it fair to say that this is a really poor design > decision? admittedly, this isn't specifically a git question, but i'm > open to opinions on something that strikes me as a bad idea. I agree that in general it's a bad idea. I can see how it happens, though, which is because two things come into tension: 1) The general desire not to check in generated files into the git repository --- including configure files generated by autoconf, Makefiles generated by automake, libtool files, etc. 2) Wanting not to give users trying to build from source a non-hostile experience. Unfortunately autoconf/automake/libtool systems are notorious for not having a stable interface, such that if you have the wrong or outdated version of the tools, the results of generating the configure, Makefile, etc., using a different version than what the developer used.... well, your results may vary. What I do is use "Maintainer mode" which means that the generated files are *not* automatically rebuilt by the build system unless you configure with --enable-maintainer-mode, and then I *do* check in the generated files into git. That way I can run with --enable-maintainer-mode, and check in updates to Makefile, configure, etc., as necessary when the input files change, but that way, end users don't have to worry getting ambushed by version skew caused by using an old (or unexpectedly newer) version of the autoconf/autoconf/libtool tools. Heck, I even have had config.guess/config.sub change on me in incompatible ways(*), so I ship my own version and don't enable a blind update of those files from the upstream FSF sources --- mainly because I don't trust them to preserve a stable interface. Better that I manually pull them into the repo, and test them before I do a public release. - Ted (*) Although to be fair it's been years since I've been screwed in this fashion. But once bitten, twice shy....