Re: Automake violations of the gnu coding conventions

[Harlan Stenn]

> Harlan Stenn wrote:
> > 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.

> Yes, this would seem to be the values set of automake.  Shorten the 
> developer cycle at the cost of the usability.  I was hoping that enough 
> time had elapsed that it might be reasonable to reevaluate this priority.

You have not communicated to me how the current situation costs
usability.

I am certainly open to win/win solutions, however.  I'm even open to
solutions that "cost" me at a clear benefit to others.

I just haven't seen how this is the case based on what I have read from
you.

It may not matter, as I am not an automake maintainer.

> > 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.

> The general benefit is in usability.

Please help me to understand, as I'm not seeing it.

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

> I've already described the use case twice.  And the response seems to be 
> that automake doesn't support those use cases.  Ok, I knew that.  
> Automake doesn't support those use cases YET.  What I'm proposing is 
> that we start supporting those use cases, directly, as a standard and 
> supported feature of automake.

OK, I'll re-read again in about an hour (errand time for me).

> >> 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?

> Yes.  Add AM_REGEN to your Makefile.am.

I'll read again, and I don't see how this does it, unless you are saying
make AM_REGEN the default case and have the "make dist*" supply an
overriding parameter to configure to have it not produce those rules in
the distributed Makefile.in files.

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

> And telling me that I must have automake installed simply in order to 
> build packages that use automake really isn't good enough either.

But as Ralf said you don't need to have automake installed.  The
'missing' script handles this case, and there must be some reason why
your timestamps are getting messed up as I have never seen a failure
case like the one you are describing either.

And this situation is even more layered - I am using GNU AutoGen for one
big project, and I do not want to require my other developers to install
it.  Therefore I check in my autogen-generated files and we use a
'bootstrap' script after doing a code checkout to make sure the
timestamps are OK.  I have a similar situation where this same package
must be developed on stock Windows boxes, so I also check in the files
generated by yacc/bison.

I'd love to have a better solution to these problems, but at least I
have a workable solution.

H