On Wed, 10 Sep 2003, Hrvoje Niksic wrote: > [ I'm Cc-ing the list because this might be interesting to others. ] > > Mauro Tortonesi <[EMAIL PROTECTED]> writes: > > > ok, i agree here. but, in order to help me with my work on wget, could > > you please tell me: > > > > * how do you generate a wget tarball for a new release > > With the script `dist-wget' in the util directory. Ideally the `make > dist' target should do the same job, but it gets some things wrong. > Take a look at what `dist-wget' does, AFAIR it's pretty clearly > written.
right. > > * 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? > > * 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? how do you update aclocal.m4? please, notice that i am __NOT__ criticizing this. i only want to know what's the update/maintenance procedure for these files, and possibly the rationale behind it. > > * how do you generate/maintain automake-related files > > (e.g. aclocal.m4, mkinstalldirs, install-sh, etc...) > > 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 a bug is discovered, you can get the latest version from the latest > Autoconf or wherever. ok. > > it would be impossible for me to keep working on the > > autoconf-related part of wget without these info. > > I hope the above helped. There's really not much into it. yes, certainly. > > BTW: could you please tell me what of these changes are acceptable > > for you: > > > > * Re-organized all wget-specific autoconf macros in the config > > directory > > As long as you're very careful not to break things, I'm fine with > that. But be careful: take into account that Wget doesn't ship with > libintl, that it doesn't use Automake, etc. When in doubt, ask. If > possible, start with small things. ok. > > * Re-libtoolized and re-gettextized the package > > I believe that libtoolization and gettextization are tied with > Automake, but I could be wrong. I'm pretty sure that the > gettextization process was wrong for Wget. i agree with you here. > > * 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 :-) and, more important, with this approach your package may keep using broken/obsoleted autoconf macros without your knowledge. that's one of the best reasons for using automake. > > * 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. > Specifically, I don't want to cater to old buggy or obsolete IPv6 > stacks. nor do i. > That's what I liked about Daniel's patch: it was straightforward and > seemed to do the trick. If at all possible, go along those lines. if you want a good IPv6 support, then you'll have to add a bit of complexity to the autoconfiguration process. Daniel's patch is incomplete because: * it does not detect the ipv6 stack flavour (and most important it doesn't check if wget should be linked against libinet6) * it doesn't check if getaddrinfo supports AI_ADDRCONFIG, AI_ALL, AI_V4MAPPED flags * it does not check if the system supports struct sockaddr_in6 * it does not check if struct sockaddr_in6 has the sin6_scope_id member (not so important for wget) * it checks if ipv6 is supported at compile time disabling ipv6 support if it cannot create a PF_INET6 socket - this is a broken behaviour because the user may have forgot to load the ipv6 kernel module and still want wget to compile with ipv6 support for a good IPv6 autoconfiguration example, see nc6: http://cvs.deepspace6.net/view/nc6/ or, even better, oftpd: http://cvs.deepspace6.net/view/oftpd/ > > * Re-named configure.in to configure.ac and modified the > > file for better autoconf 2.5x compliance > > That's fine, as long as it's uncoupled from other changes. > Specifically, it should be possible to test all Autoconf-related > changes. ok. > > * Added profiling support to the configure script > > I'm not sure what you mean here. Why does configure need to be aware > of profilers? in fact, it doesn't. but it would be nice to have a new --enable-profiling switch for configure that lets the user build wget with profiling information. not so important, however. > > * Re-named the realclean target to maintainer-clean in the > > Makefiles for better integration with po/Makefile.in.in and > > conformance to the de-facto standards > > That should be fine. ok. > > * Modified the invocation of config.status in the targets in the > > "Dependencies for maintenance" section of Makefile.in, according > > to the new syntax introduced by autoconf 2.5x > > I haven't studied the new Autoconf in detail, but I trust that you > know what you're doing here. i have made the changes following the autoconf 2.5x manual, so they should be fine. > > util/Makefile.in: added rmold.pl target, just like texi2pod.pl > > in doc/Makefile.in > > > > src/wget.h: added better handling of HAVE_ALLOCA_H and changed > > USE_NLS to ENABLE_NLS > > Sounds fine. BTW what do you mean by better handling of > HAVE_ALLOCA_H? form the autoconf 2.5x manual: - Macro: AC_FUNC_ALLOCA ... Source files that use `alloca' should start with a piece of code like the following, to declare it properly. In some versions of AIX, the declaration of `alloca' must precede everything else except for comments and preprocessor directives. The `#pragma' directive is indented so that pre-ANSI C compilers will ignore it, rather than choke on it. /* AIX requires this to be the first thing in the file. */ #ifndef __GNUC__ # if HAVE_ALLOCA_H # include <alloca.h> # else # ifdef _AIX #pragma alloca # else # ifndef alloca /* predefined by HP cc +Olibcalls */ char *alloca (); # endif # endif # endif #endif > Do you actually know that Wget's code was broken on some platforms, > or are you just replacing old Autoconf boilerplate code with new one? i am just following the directives of the autoconf 2.5x manual. -- 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
