[vorbis-dev] Bug fix, win32 stuff

[Monty]

> OK. We need 2 seperate things: appropriate definitions for public types,
> and various internal #defines, typedefs, etc. 

Actually, we need a third; wrappers for asm or alternate math strategies.  Eg,
we really do want hypot() with glibc, but we also want to avoid it under Win32
where sqrt(x*x+y*y) is much faster.

> I think the first is best served by a single file (independent of the
> platform). Perhaps vorbis_types.h? Something along those lines, anyway.
> This would bring quite a few #ifdefs into this file, but they will be
> relatively simple, and it's going to be unavoidable unless we have seperate
> files depending on platform (which is a bad thing, for external headers).

I maintain it is not a bad thing, if kept to a minimum.  My assertion is that 
the platform headers would divide down along the 'Unix/everything else' lines, 
not sure exactly where BeOS falls.  It *appears* ugly at first glance, but 
then you realize:

No #ifdef rats' nests
All the platform specific code is compartmentalized
There can be no confusion which one should use
Easy to maintain

That list looks like some strong wins to me.

> Then, for internal headers, we have os.h - perhaps this could be changed to
> have no real contents at all, just a simple set of 
> 
> #ifdef platform1
> #include <os_platform1.h>
> #endif

Something very much like that, yeah.

> Then each platform header would define anything required (other than the
> public types - we can just include the public header there). Right now,
> this would just be a single os_win32.h, as you suggested - others will
> doubtless be added later (for example, vorbis wouldn't compile on a solaris
> machine I was using a while back, since u_int* weren't defined. This would
> be easily fixed by an os_unix.h, but the machine also didn't have GNU Make
> on it, so I gave up - I'll get back to that some time).
> 
> This would seem to keep things fairly clear, though the number of little
> files would increase a fair bit.

Not really... Most of the subtle OS flavoring involved is UNIX and UNIX can be
controlled entirely in autoconf.  The other OSes are not going to be (easily)
coaxed to use GNU tools (win32 and BeOS are partial exceptions, but the point
still applies), so we take the shortest clean route to easy maintainence (which
is the real concern in 'clean' programming).

Also note that this is *sort of* what autoconf is trying to automate; building
a config.h for the platform on which you're currently building.  We, instead,
are rolling the equivalent of config.h by hand.  I've had enough years of
experience with autoconf at this point to vote for chucking it out the window
as I often have to fix the configure.in for every new platform that I run
across anyway :-P

Monty

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/