[vorbis-dev] Please gix getopt

[Michael Smith]

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

They're functionally different, though. If they did the same thing, then
it wouldn't be an issue. The GNU getopt_long() is more useful. Since we
have to include a copy of getopt anyway (for the several non-unix
platforms vorbis-tools (well, oggenc and probably vorbiscomment)
support), it's best to use one that we can just take and use, without
having to have things work differently on different platforms.

> 
> > > 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.

No, it isn't. Other platforms DO NOT have gnu getopt. 'standard' unix
getopt is, again, NOT THE SAME. It does different things differently.
Having the behaviour be different depending on what unix you're using is
not an option.

> 
> 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.

And I agreed with moving it into a seperate directory. The name-shifting
doesn't solve any known problems, and adds complexity.

> > 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.  :-)

Then it's not a problem, so we don't need to do that. Fine.

> 
> 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.

Well, if you want to excise getopt() completely from our local
getopt.[ch], that'd be possible. Not sure that it's USEFUL, but it
wouldn't break anything (unless getopt_long() uses it internally, I
haven't looked). If not, we only want getopt_long, so we could just rip
out the other stuff. No real need for it, though, that I can see.

> 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:

No, it can't. This is precisely WHY C has two different ways to include
appropriate include files: #include <getopt.h> and #include "getopt.h"
have different meanings. There's no problem.

As far as I can see, there's no actual problem - you're claiming that
there MIGHT be some problem in the future on some (unknown) system, but
in doing so you're making things far more complex than they need to be.
I'm quite happy to make changes needed for real systems, though.

> 
> 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.  :-)

Your previous discussion finally got me to fix the problem with ogg123.
That works, now (as far as I know), but is sub-optimal because automake
is bloody stupid and can't do cross-directory compilation, apparently.
So we want to build a static library and just link that in - fine.

Michael

--- >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.