Braden McDaniel wrote:
On Wed, 2008-10-15 at 06:34 -0700, Dan Nicholson wrote:
> blackbox: needs AC_PROG_CXX
I see no reason at all for this to be running autoreconf. (A comment
claims it gets rid of an rpath; I'd be a little surprised if this were
still true.)
*scratches head* If this is using an old, unpatched version of libtool,
wouldn't it add the rpath until a new version of libtool is inserted
into the package? So it will be true until upstream is updated to use a
new version of libtool?
> bmpx: needs AC_PROG_CXX
Actually, the problem is that it patches both configure.ac and
configure. Presumably the timestamps don't line up right as a result
and "make" triggers regenerating stuff. Either the patch to
configure.ac should be culled or the timestamps need massaging.
(There's also a patch to soup.m4 that just looks goofy.)
Please stop giving bad advice (I think you're doing it in the interests
of brevity but still.) Telling people to have two patches, one for
configure.ac and one for configure and making sure the configure.ac
patch is applied before the configure patch is good advice, continue
doing that! But using phrases like "or do it right and patch configure"
and "the patch to configure.ac should be culled" is bad advice; it
leaves people who read this thread and do not understand autotools with
the idea that a patch to configure *alone* is the best way to make
changes. This is not true as we still want to have something to send to
upstream and a patch to configure, Makefile.in, or any other generated
files is not what upstream wants to see.
That's why I think an informational page about autotools stuff is
desirable. It can explain the primary importance of patching the source
files (configure.ac, Makefile.am) and sending those patches upstream.
Then it can talk about the pros and cons of both methods of dealing with
the generated files so maintainers can see what they're getting
themselves in for if they choose one route over the other.
-Toshio