Mauro Tortonesi <[EMAIL PROTECTED]> writes:

>> AFAIR wget.pot is generated by Makefile.  (It should probably not be
>> in CVS, though.)  Makefile.in.in is not generated, it was originally
>> adapted from the original Makefile.in.in from the gettext
>> distribution.  It has served well for years in the current form.
>
> ok. i'll see if the new Makefile.in.in which ships with the latest
> gettext is worth an upgrade.

Note that Wget's Makefile.in.in is likely quite different than the
canonical version because of the lack of libintl bundling.  That's as
it should be.

>> > how do you update aclocal.m4?
>>
>> Wget's aclocal.m4 only contains Wget-specific stuff so it doesn't need
>> special updating.  The single exception is, of course, the
>> `libtool.m4' part which needs to be updated along with ltmain.sh, but
>> that is also rare.  I really think aclocal.m4 should simply be
>> INCLUDEing libtool.m4, but I wasn't sure how to do that, so I left it
>> at that.  (Note that I wasn't the one who introduced libtool to Wget,
>> so it wasn't up to me originally.)
>
> ok, so you simply take libtool.m4 or maybe only a part of it, and add all
> wget-specific macros to it.

Or the other way around: leave Wget-specific macros and replace
libtool.m4 contents.  aclocal.m4 has this part:

# We embed libtool.m4 from libtool distribution.

# -- embedded libtool.m4 begins here --

    [ ... contents of libtool.m4 follows ... ]

# -- embedded libtool.m4 ends here --

When you need to update libtool.m4, you do the obvious -- replace the
old "contents of libtool.m4" with the new contents.

As I said, it would be even better if it said something like
AC_INCLUDE([libtool.m4]) (or whatever the correct syntax is), so you
can simply drop in the new libtool.m4 without the need for editing.

>> Shouldn't we simply check for libinet6 in the usual fashion?
>
> this could be another solution. but i think it would be much better
> to do it only for kame and usagi stack.

Hmm.  Checking for "stacks" by names is not the Autoconf way.  Isn't
it better to test for needed features?  Daniel's test was written in
that spirit.

>> Furthermore, I don't think that Wget uses any of those flags.  Why are
>> should an application that doesn't use them care?  Note that I ask
>> this not to annoy you but to learn; you obviously know much more about
>> IPv6 than I do.
>
> well, it is very important using AI_ADDRCONFIG with getaddrinfo. in this
> way you get resolution of AAAA records only if you have ipv6 working on
> your host (and, less important, resolution of A records only if you
> have ipv4 working on your host). dns resolution in a mixed ipv4 and ipv6
> environment is a nightmare and AI_ADDRCONFIG can save you a lot of
> headaches.

Very interesting.  So what you're saying is that programs that simply
follow the getaddrinfo man page (including IPv6-enabled Wget in
Debian) don't work in mixed environments?  That's really strange.

Reply via email to