bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] Wget 1.12 v. VMS


From: Steven M. Schweda
Subject: Re: [Bug-wget] Wget 1.12 v. VMS
Date: Fri, 25 Sep 2009 21:40:17 -0500 (CDT)

From: Micah Cowan

> Steven M. Schweda wrote:
> >    7a.  Lacking Unix-like builders, I stuck some place-holders for
> > "compilation_string" and "link_string" into "src/vms.c":
> 
> Is there no equivalent that could be used in the VMS builders? If not,
> the NULL check seems reasonable to me.

   I know of nothing.  The compiler options are revealed in a compiler
listing file, and the linker options may be revealed in a linker map
file, but none of that stuff would be easy to obtain, or, I claim, of
particular interest to the user.

> >    And, speaking of build-related info, would it be useful on other
> > system types to include an indicator of large-file support somewhere in
> > this stuff?  (Or has large-file support become so common that no one
> > else worries about it now?)  A "sizeof off_t" test would be good enough
> > for me.
> 
> It can't hurt.

   You say that now.

   And, as the author of much sloppy code, I hate to complain -- Well, I
enjoy it, but I'm reluctant -- but in "src/main.c":

      [...]
      /* defined in version.c */
      extern char *version_string;
      extern char *compilation_string;
      extern char *system_getrc;
      extern char *link_string;
      /* defined in build_info.c */
      extern char *compiled_features[];
      [...]

Isn't this why the Great Sprit gave us header files?  Especially, for
example, when the real "compiled_features" is declared differently
("src/build_info.c"):
      const char* (compiled_features[])
(And do those parentheses really do anything?  My "cdecl" says no.)

   At the moment, what I have looks like this:

[...]
extern const char *compiled_features[];  /* I fixed only this one. */
[...]
  int i;
                /* Changes begin. */
  int j;
  int line_length;
  const char *runtime_features[] = { "/", NULL, NULL };
  const char **features[] = { compiled_features, runtime_features, NULL };

  /* Fill runtime_features[].  Be sure to leave an array-terminating NULL. */
  if (sizeof (off_t) >= 8)
    runtime_features[1] = "+large-file";
  else
    runtime_features[1] = "-large-file";

  printf (_("GNU Wget %s built on %s.\n\n"), version_string, OS_TYPE);
  /* compiled_features is a char*[]. We limit the characters per
     line to MAX_CHARS_PER_LINE and prefix each line with a constant
     number of spaces for proper alignment. */
  printf (_("Compile-time/Run-time features:\n"));
  line_length = MAX_CHARS_PER_LINE - TABULATION;
  printf ("%*c", TABULATION, ' ');
  for (j = 0; features[j] != NULL; )
    {
      for (i = 0; features[j][i] != NULL; )
        {
          int len = strlen (features[j][i]) + 1;
          line_length -= len;
          if (line_length < 0)
            {
              printf ("\n%*c", TABULATION, ' ');
              line_length = MAX_CHARS_PER_LINE - TABULATION - len;
            }
          printf ("%s ", features[j][i]);
          i++;
        }
      j++;
    }
  printf ("\n");


Here, the result looks like this:

ALP $ wgxl --version
GNU Wget 1.12 built on VMS Alpha V7.3-2.

Compile-time/Run-time features:
    +digest +ipv6 -nls +ntlm +opie +md5/builtin +https -gnutls +openssl
    -iri / +large-file
Wgetrc:
    SYS$LOGIN:.wgetrc (user)

Copyright (C) 2009 Free Software Foundation, Inc.
[...]

   I haven't checked it for portability problems (what could go wrong?)
but I claim that this code actually does limit the line length properly
(although I didn't trim that trailing space), and it really is indented,
as the comment suggests.  It was so easy to toss in that "/" separator
between the two classes of items, that I couldn't resist, but it's easy
to remove, if desired.  Lots of formatting changes could be made, of
course.  And the new array could be relegated to some other backwater,
like "src/build_info.c", or some new module.

   I figured that I'd suck down a fresh source kit soon, and whip up
some patches against the current stuff, and also assemble a kit of new
VMS-specific files (source and builders) for incorporation.  More VMS
builder changes may be needed, but I think that I have something usable
now, and it might be nice to get it into the mainstream, so that an
adventurous VMS user could try it.  (I assume that a normal victim will
have trouble where I don't.)

   I'd also like to see if there's an easy way to auto-generate a VMS
help file from the "wget -h" output, but that may be a while.

   Opinions welcome, as always.

   SMS.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]