Status of libtool 2.2.X?

[Toshio Kuratomi]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/57d9ef21/attachment.sig>