[vorbis-dev] Please gix getopt

[Jeff Squyres]

Sidenote: we could avoid this whole issue by only using getopt(), and not
using getopt_long().

I thought I'd point this out before launching into this e-mail... :-)

On Mon, 12 Feb 2001, Michael Smith wrote:

> > a) the getopt* files should be moved into vorbis-tools/getopt/
> > b) all the types and symbols should be renamed to have an "ov_" prefix

After some more conversations on #vorbis, I can agree to ditch the "ov_"
prefix.  I only suggested it as a compromise to begin with (see the bottom
of this e-mail).

> > c) they should be compiled into libovgetopt.a (no need for shared)
> > d) oggenc, ogg123, and vorbiscomment should -lovgetopt

> This needlessly and wastefully links in a copy of getopt on GNU
> systems, where getopt already exists. There's NO reason to do that.

Er... but this is *exactly* what is currently done on POSIX systems that
don't use GNU libc (all POSIX systems have getopt()).  Linux is not the
only flavor involved here.

Also, we have 2 copies (potentially 3, because vorbiscomment uses
getopt_long()).  All I said was move getopt* to a single directory and
name shift it.

This is actually a nontrivial issue.  Any given system will have zero or
more of the following:

        getopt()
        getopt_long()
        <getopt.h>
        prototype for getopt() elsewhere

> Can you name a system where the duplicated symbols (between the
> included GNU getopt and the system's getopt) actually causes
> compilation _errors_, that are difficult or impossible to work around?

You may be right; there may not be a problem with multiple symbols.
However, I don't really feel like trying all kinds of different systems.
It is certainly *possible*, though.  :-)

A better way of saying what I meant was that getopt() should be totally
separated from getopt_long().  Name shifting was one way to sidestep the
entire issue, but it's really a cop-out, and you're right -- it's not the
Right thing to do.

Abstractly speaking, there are really *four* entities involved:

        1. getopt()
        2. prototypes for getopt() and its associated extern variables
        3. getopt_long()
        4. prototypes for getopt_long(), struct option, etc.

POSIX systems will already have 1 and 2.  As someone pointed out to me
earlier today, win32 systems won't, so we still need to include them in
vorbis-tools.

Non GNU libc systems will not have 3-4.  So we need to include those in
vorbis-tools as well.  But these two should *not* imply 1-2 (currently,
they do).

So there should be four corresponding files:

        getopt.c: definition for getopt(), instantiations of optind, etc.
        ov_getopt.h: prototype for getopt(), declarations of optind, etc.
                Yes, the name-shifted filename is on purpose, see below.
        getopt_long.c: definition of getopt_long() and friends, including
                the definition of _getopt_internal() (and all associated
                helpers)
        getopt_long.h: prototype for getopt_long() and friends,
                declaration of struct option, etc.

We can't have a "getopt.h", because it could clash with an OS "getopt.h"
(e.g., Linux).  The code will look like this:

-----
/* Does the OS provide getopt.h, or do we have to use the included one? */
#if HAVE_GETOPT_H
#include <getopt.h>
#else
#include "ov_getopt.h"
/* ... or directly have all the relevant stuff right here .... */
#endif

/* Now check to see if the OS has getopt_long().  If it doesn't, it
   certainly doesn't have a prototype for it, either */
#if !HAVE_GETOPT_LONG
#include "getopt_long.h"
#endif
-----

This should probably all be hidden in ov_getopt.h, and oggenc, ogg123, and
vorbiscomment can just #include <ov_getopt.h>.  They can all then use
getopt_long() and optind, etc., as they already do.

Some simple automake-izms will determine if the included getopt.c and
getopt_long.c get compiled or not.

> Having only a single copy and linking it into each program is good
> (the only reason I added a second copy for ogg123 is that nobody else
> was going to fix it, at the time, and I wasn't going to do automake
> crap). A worthwhile change.

Agreed.

While this may seem to be a totally mundane issue to argue about, I do
believe that it should be Right, so it is worth a little discussion here
on the list.  And once we agree on what is Right, I am willing to spend
the time to write the code to do it (configure.in, Makefile.am, etc.).
So when we agree on the Right solution, I will submit a patch.

> Modifying the sources pervasively like this is definately not good,
> however.

I agree with this as well; I did the name shifting only as a compromise
because none of my previous discussion on this topic generated any
responses, and compiles still failed on Solaris.  Hence, I wanted to do
*something*.  As mentioned above, name-shifting side-stepped the whole
issue, so that's what I did.

It finally generated discussion, too.  :-)

{+} Jeff Squyres
{+} squyres at cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.