Jeff Garzik wrote: > On 12/06/2010 12:44 PM, Pete Zaitcev wrote: >> On Mon, 06 Dec 2010 12:32:22 -0500 >> Jeff Garzik<jeff@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe hail-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
