[Openal-devel] Linux Packages
Sven.Panne at BenQ.com
Thu Jan 5 06:36:09 PST 2006
> -----Original Message-----
> From: openal-devel-admin at opensource.creative.com
> [mailto:openal-devel-admin at opensource.creative.com] On Behalf
> Of Ioan Rogers
> Sent: Donnerstag, 5. Januar 2006 14:41
> To: openal-devel at opensource.creative.com
> Subject: RE: [Openal-devel] Linux Packages
> I'd personally prefer something like openal-1.0, as it would
> at least inform the user it's a 1.0 spec library. As you
> said, 0.0.9 sounds a bit pants. However, I'm not really even
> sure HOW much of the 1.0 spec 0.0.8 implements. So maybe 0.9
> would be better?
If I'm not mistaken the current "portable" module implements all of
OpenAL 1.0, so this is not an issue. I think that we should really keep
the spec versions and the release versions separate, other projects like
Mesa do this in a simlar way. We need to be able to distinguish at least
bugfix-only releases from releases with new functionality and/or
differing internals. This implies two numbers, and adding the spec
version in front of those would result in something like "220.127.116.11",
which is a bit complicated IMHO. Something like "X.Y" for normal
releases and "X.Y.Z" for bugfix-only releases makes more sense and is
much more common. So my proposal is simply to bump the version number to
"1.0" now, and you can start practicing to make packages for the
platforms you've mentioned. When I've finished my backend cleanup (which
will hopefully not take too long) I can tag a 1.0 release candidate, we
can test on as many platforms as possible then and get 1.0 out of the
door rather soon. ("Release early, release soon."
> [...] I'll leave out SMPEG, and put the rest in, as they all seem
> to have very common dependencies. Or does anyone know if the
> smpeg backend is ever really used?
SMPEG is not a backend, it is the support for MP3 via an extension
(similar to the Vorbis stuff). The configure flag was actually a
misnomer, so I've renamed it to --enable-mp3 recently. Is SMPEG not
supported on Ubuntu and Slackware? Perhaps I can try to make these
extensions use dlopen, too, so there are no hard dependencies on
libvorbis and SMPEG on the target machines. In any case, to avoid
fragmentation I'd like to see as many extensions supported as possible
if that's not a problem.
> The MP3 Support is a loki extension, correct? I can't find
> any configure or cmake option to turn that off anyway. As for
> the vorbis, I'll put it in too, if it's expected. I assume
> that it'll disappear in 1.1 though?
The configure flags are --disable-vorbis and --disable-mp3. Furthermore,
I don't think that these extensions will disappear, they are not hard to
implement and they are quite handy.
More information about the Openal-devel