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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
