From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Meyering Subject: Re: AC_CONFIG_MACRO_DIR([m4]) Date: Mon, 06 Dec 2010 20:26:46 +0100 Message-ID: <8739qawvm1.fsf@meyering.net> References: <20101205145655.4f91e5d6@lembas.zaitcev.lan> <4CFD1E26.8010908@garzik.org> <20101206104419.5a7205e5@lembas.zaitcev.lan> <4CFD31E5.2090508@garzik.org> Mime-Version: 1.0 Return-path: In-Reply-To: <4CFD31E5.2090508@garzik.org> (Jeff Garzik's message of "Mon, 06 Dec 2010 13:56:37 -0500") Sender: hail-devel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Jeff Garzik Cc: Pete Zaitcev , hail-devel@vger.kernel.org Jeff Garzik wrote: > On 12/06/2010 12:44 PM, Pete Zaitcev wrote: >> On Mon, 06 Dec 2010 12:32:22 -0500 >> Jeff Garzik wrote: >> >>> Keeping the "correct libtool macros in-tree" implies adding a pointless >>> maintenance burden. The distro always gives us correct, up-to-date >>> files. Why would hail want to potentially lag upstream's version of >>> these macros, forcing us to manually track macros that are currently >>> updated automatically for each ./autogen.sh invocation? >> >> I presumed that the important part is a compatibility between the >> syntax used in various .am files and the libtool scriptography that >> underpins them. "Lagging" upstream has no downside in this case >> (unlike zlib, where security fixes may exist). > > It does not seem optimal to run a current libtool with outdated macro > files. In all cases except current one, you're checking in third > party, maintained, versioned files to hail.git where they will be > less-well maintained, and generally out-of-date vis a vis current > [upstream | Fedora]. Hi Jeff, The patch that adds those two lines does not (and IMHO should not) imply that a project would version-control those files. Typically, those symlinks exist only in your working directory, and not in any project's VC repository. If you have no other files in m4/, you can simply .gitignore the entire m4/ directory. > Where is the value in performing this additional work, besides > silencing a warning seen only by git repo users? Yeah, either way it's not a big deal.