autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bin/Makefile.am: merge the rules


From: Stepan Kasal
Subject: Re: bin/Makefile.am: merge the rules
Date: Fri, 20 May 2005 11:37:56 +0200
User-agent: Mutt/1.4.1i

Hello,

some time ago, I submitted this patch:
http://lists.gnu.org/archive/html/autoconf-patches/2005-01/msg00093.html

Paul Eggert answered:
> That change saves six source lines, but there are some downsides;
> e.g., if someone inadvertently creates autoheader.in in the working
> directory, it will use that file rather than $(srcdir)/autoheader.in.

At that time I accepted that objection.

Now I think I should have replied:

1) The main purpose is not to "save six lines", but to express clearly
that all the scripts are generated bu the same set of commands.

2) If you create file config.h.in in the build tree, a subsequent run of
config.status will inadvertently use it.
You are simply not allowed to coin *.in files here and there.

The thread continued in Feb 2005, and I submitted some inferior versions
of my patch.  In certain phase, Paul said:
> [...] this approach causes the output of "make" to be harder to follow.

If I considered this objection related to my _original_ submission
referenced above (it wasn't meant this way, though), I'd say that the
idiom `test -f ./$@ || echo $(srcdir)` is used heavily in Makefiles,
I guess it's brought there by Makefile.am.
Compared to the preceding $(edit) which is almost 7 lines long, I don't
see any significant decrease of readability.

Considering all this, I'm still not convinced that my original patch,
submitted in the message referenced above, was wrong.

I'd like to commit it.  Paul, will you let me to do it?

Have a nice day,
        Stepan Kasal




reply via email to

[Prev in Thread] Current Thread [Next in Thread]