On Wed, 10 Sep 2003, Hrvoje Niksic wrote:
> Mauro Tortonesi <[EMAIL PROTECTED]> writes:
>
> >> > * how do you generate/maintain gettext-related files (e.g. the files in
> >> > the po directory
> >>
> >> The `.po' files are from the translation project. POTFILES.IN is
> >> generated by hand when a new `.c' file is added.
> >
> > ok, but what about Makefile.in.in and wget.pot?
>
> 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.
> >> > * how do you generate/maintain libtool-related files
> >> > (e.g. ltmain.sh)
> >>
> >> When a new libtool release comes out, ltmain.sh is replaced with
> >> the new one and aclocal.m4 is updated with the latest libtool.m4.
> >> config.sub and config.guess are updated as needed.
> >
> > do you mean that you simply copy these files manually from other
> > packages?
>
> Yes. I don't do that very often.
i can imagine ;-)
> > 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.
> > please, notice that i am __NOT__ criticizing this.
>
> Don't worry, I'm not reading malice in your questions. All your
> questions are in fact quite valid and responding to them serves to
> remind myself of why I made the choices I did.
very good :-)
> >> that probably hasn't changed for years.
> >
> > i am not so sure about this.
>
> If they've changed and if updating them won't break anything, feel
> free to update them. (In a separate patch if possible.:-)).
ok, but i don't care too much about this.
> >> > * Updated aclocal.m4, config.guess, config.sub
> >>
> >> Note that Wget doesn't use a pre-generated (or auto-generated)
> >> aclocal.m4. Updating config.guess and config.sub is, of course, fine.
> >
> > how do you maintain aclocal.m4, then? by hand? this seems a bit too
> > "manual" for me :-)
>
> I believe Wget's aclocal.m4 is quite different from the ones in
> Automake-influenced software. I could be wrong, though. Please take
> another look at it, and please do ignore the libtool stuff which
> should really be handled with an include.
ok.
> > and, more important, with this approach your package may keep using
> > broken/obsoleted autoconf macros without your knowledge.
>
> I'm not so sure about that. The way I see it, Wget's configure.in and
> aclocal.m4 use documented Autoconf macros. Unless Autoconf changes
> incompatibly (which they shouldn't do without changing the major
> version), they should keep working.
ok.
> >> > * Added IPv6 stack detection to the configuration process
> >>
> >> Please be careful: Wget doesn't need the kind of stack detection that
> >> I've seen in many programs patched to support IPv6.
> >
> > i am afraid you're wrong here. usagi or kame stack detection is
> > necessary to link the binary to libinet6 (if present). this lets
> > wget use a version of getaddrinfo which is RFC3493-compliant and
> > supports the AI_ALL, AI_ADDRCONFIG (which is __VERY__ important) and
> > AI_V4MAPPED flags. the implementation of getaddrinfo shipped with
> > glibc is not RFC3493-compliant.
>
> 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.
> 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.
but you have to handle the AI_ADDRCONFIG flag with care; first of all you
must check that the system supports it and then you mustn't treat
"unsupported family" socket errors as fatal. please, see nc6 code for
this. i'll send a patch for this ASAP.
--
Aequam memento rebus in arduis servare mentem...
Mauro Tortonesi [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Deep Space 6 - IPv6 with Linux http://www.deepspace6.net
Ferrara Linux User Group http://www.ferrara.linux.it
