Re: [Bug-wget] Wget 1.13.4 v. VMS -- Various problems

[Micah Cowan]

On 09/27/2011 10:22 PM, Steven M. Schweda wrote:
>     It's still early, but here are the initial complaints...
> 
>     "lib/snprintf.c" now ignores HAVE_SNPRINTF.  In previous wget
> versions, I could compile "snprintf.c" and not get a redundant
> snprintf() if HAVE_SNPRINTF was defined ("%LINK-W-MULDEF, symbol
> DECC$TXSNPRINTF multiply defined").  I can supply a conditional jacket
> for "snprintf.c", but should I need to (now)?

lib/snprintf.c is imported directly from outside (from gnulib), so
there's not going to be a lot of control exercised over it from a
wget-developer perspective. I'm sure if it came to it, some sort of
patch-application phase could be added, but I imagine that Giuseppe
would be resistant to such a thing until it were truly necessary.

Gnulib in general doesn't use HAVE_FOO as the sole determiner of whether
to use something. It will happily supply its own snprintf if it thinks
for even one second that the system's snprintf isn't perfect. Which
mostly means, doesn't do exactly everything the latest glibc's does, the
way it does it. Whether you actually needed that particular feature or not.

But, on the other hand, when it chooses to supply its own, it carefully
macros it away so that the real linker name is something different.
However, the way it does this (and the way it decides whether to even
build sprintf.c in the first place), is embedded in the expected process
that the user will use the ./configure script to set up the environment
and determine which bits from gnulib to include; doing it any other way
(as you're attempting) is bound to be painful. I wonder if it might be
worth it to run ./configure under a POSIX-compatible shell thing to
produce sane build stuff (assuming other VMSen will be similar enough to
use whatever results?), and then include the results in your offering?
That violates the philosophy behind autoconf, of course, makes it closer
to an Imake thing, but then you're not going to make them use it anyway,
so might as well see if you can use it yourself to make life at least a
little easier.

In this case, the logic that does a rename of snprintf seems to be at
the end of "vasnprintf.h" rather than directly in snprintf.c.

-- 
Micah J. Cowan
http://micah.cowan.name/