Re: mingw.org-wsl .gitignore

On 10/10/12 11:01, Charles Wilson wrote:
> On 10/9/2012 4:01 PM, Keith Marshall wrote:
>>> aclocal.m4
>>
>> Uhmm, no.  This is a fundamental, maintainer written component of the
>> build system; it should be tracked.
>
> Not if automake/aclocal is used. In that case, aclocal.m4 is generated
> and acinclude.m4 is handwritten. Dunno if that applies in this case.

It doesn't.  See my earlier reply to Earnie, which crossed with this in 
the "post".

>>> missing
>>> depcomp
>>> install-sh
>>
>> Aren't these build-aux candidates?  We can either import each of them
>> individually, and explicitly, or we can import all of build-aux as a
>> submodule.  Either way, it seems wrong to ignore them.
>
> They are build-aux candidates. The files are maintained by the automake
> project, and will get copied into AC_CONFIG_AUX_DIR by automake/autoreconf.
>
> I repeat my original statement that IF automake is used, then build-aux/
> ought contain neither tracked files nor a submodule, but instead should
> be an empty dir populated by running automake --add-missing --copy (or
> autoreconf -i)

With respect, I *strongly* disagree with this, on a conceptual basis. 
See, this is one of those problems that automake *creates*, (rather than 
solves); if you are going to allow automake to populate your build-aux 
directory, (using --add-missing), that's a step which should be 
performed only once, by the lead maintainer of the package.  Thereafter, 
the imported files *must* be tracked within the project, independently 
of any external changes made by the automake folks.

If we follow your recommendation, then we create potential for you and I 
to have subtly different versions of the imported files within our 
supposedly current working trees, and who's to say which of us has the 
definitively correct representation of the project state?  Please don't 
go there; this is the stuff of which nightmares are made.

> Now, if automake is not in use, well...I prefer explicitly tracked files
> to submodules, because the former gives greater control over OUR build
> system, and the latter...submodules suck. :-)

In your opinion, maybe.  With the exception of the disappearing gitlink 
issue, (which actually hasn't created any real problem for me anyway), 
having build-aux as a *mercurial* submodule is working just fine for me. 
  However, if we're talking *git* submodules, then I tend to agree: it 
appears to me that git's submodule implementation *does* suck.

-- 
Regards,
Keith.

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev