Re: [PATCH] Fix typo in Makefile.am to make it agree with Makefile.in.

[John Darrington <john at darrington dot wattle dot id dot au>]

On Sun, May 06, 2018 at 08:21:17AM -0700, Jim Wilson wrote:
     On Sun, May 6, 2018 at 5:44 AM, John Darrington
     <john@darrington.wattle.id.au> wrote:
     > What on earth are files such as Makefile.in,  configure, and many other
     > generated files doing in the repository in the first place?
     
     To make it easier for end users to build binutils sources.  To
     regenerate Makefile.in, I had to build and install the specific
     version of automake that is the same as the one used to build it in
     the first place.  This is an unreasonable requirement for end users
     who just want to build the sources.

I'm not for one moment suggesting those files be removed from the tarball! - just
from the repository.   End users don't build from the repo - or at least
that's not what it's indended for - so it won't make any difference for them.
     
     > I suggest that all generated files are removed from the repo, (and a bootstrap
     > script, or auxiallary Makefile be introduced to regenerate them).
     
     There are already build rules for this.  Use --enable-maintainer-mode
     when configuring binutils.

That is good to know.  I will try it.
     
     I can't support removing the generated files from the repo.  I think
     that will cause more trouble than it will fix.  I also think that it
     won't solve the problem.  The problem arose because Makefile.in was
     accidentally edited instead of Makefile.am.  If Makefile.in is created
     at build time, then you still have it in your tree, and you can still
     accidentally edit it.  It only Makefile.am is checked in, then we
     would not have noticed the inconsistency, and it would likely have
     taken far longer to notice and fix the problem.  So having both
     Makefile.am and Makefile.in helps to catch these kinds of errors.
     
I'm not sure that I follow the logic here.  It is true that if a non-source file
is manually changed, then bad things will happen.  But we accept that for object files,
output binaries, lex and yacc generated C files, gperf output etc, etc, etc.
Why apply a different rule for autotools?

It's also true that particular automake versions are required, but again,
since it's not intended for end use consumption, I don't see this as a
big price to pay.

Just my $0.02


-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature