Re: Automake violations of the gnu coding conventions

[Harlan Stenn]

> Harlan Stenn wrote:
> > I really dislike this proposal as it stands.
> >
> > While I'm fine with a position that says "for normal users, don't have
> > Makefile.in depend on Makefile.am", I *want* that rule as a package
> > developer and even as a release engineer.
> >
> > I already have way too much stuff I have to remember to do, and adding
> > an extra step to make sure that generated files are up-to-date is just
> > asking for more work and problems.

> distcheck could also be used to verify this based on file stamps and to 
> provide a reminder.

I'll say it again - I am not interested in a reminder, I am interested
in being efficient at maintaining software packages.  This means
*shortening* the development cycle.

> > Put another way, if somebody want to have sufficient mechanism to allow
> > these behaviors as choices, and if somebody wants to have a way to
> > specify that strict GNU coding policy can be used that's fine with me.
> > Just be sure to make it trivial enough that I can override that policy
> > choice locally so I can work more efficiently.

> I think we're all agreed on this.  The question is whether the onus for 
> difference should be placed on the user or on the developer.  In both 
> cases, the deviation is intended to be trivial.  However, a developer is 
> expected to understand that the change is necessary and how to make it 
> while a simple builder may not.

I'm saying "mitigate the onus".

While it's debatable if your deviation is trivial, speaking from my
experience implementing your proposal will definitely cost me time and
effort, and I do not see any offsetting general benefit.

I agree with Ralf - can you demonstrate an example of the problem you
are trying to solve?

> In what way does my proposal fail to address your needs?

Where is the trivial way I can change your default policy so I can work
as efficiently as I do now?

Telling me to remember to run a different target is not good enough.

H