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. >> > * 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. > 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.) > 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. >> I don't use Automake. mkinstalldirs and install-sh are standard >> Autoconf stuff > > true. > > >> 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.:-)). >> > * 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. > 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. >> > * 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? 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. I have to go now; I'll answer the rest of your message separately. Thanks for your patience and for the detailed reply.
