[issue16902] Add OSS module support for Solaris

2013-01-10 Thread brian-cameron-oracle

brian-cameron-oracle added the comment:

Since Modules/ossaudiodev.c has the following line (which is not surrounded by 
any conditional #ifdef sort of things):

#include sys/soundcard.h

This means that the OSS plugin will only build on a system that has this header 
file, so it is safe to check for on any system.  How can the Module code build 
if the header can't be found?

The code will only compile if the CFLAGS used when building the
module is setup to include /usr/include or /usr/local/include, but
this is normally taken care of by default.

If users need to specify their OSS headers are in some weird 
non-standard location, then they can use CFLAGS or other Makefile mechanisms to 
specify the compiler arguments they would then need to build anything that uses 
their non-standard OSS.

Or am I just confused by your question?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue16902] Add OSS module support for Solaris

2013-01-09 Thread brian-cameron-oracle

New submission from brian-cameron-oracle:

Solaris supports OSS, but the attached patch is needed to get it to build.

Note that some of the EXPORT_INT lines in Modules/ossaudiodev.c need to be
#ifndef'ed out on Sun since OSS on Solaris doesn't support them all. 

Does it make sense to use #ifndef like this, or should each EXPORT_INT be 
encapsulated by its own #ifdef?

--
components: Extension Modules
files: ossaudiodev.patch
keywords: patch
messages: 179424
nosy: brian-cameron-oracle
priority: normal
severity: normal
status: open
title: Add OSS module support for Solaris
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file28644/ossaudiodev.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue16902] Add OSS module support for Solaris

2013-01-09 Thread brian-cameron-oracle

brian-cameron-oracle added the comment:

OSS is the default audio system in Solaris 11 and 12.  In Solaris 10 and 
earlier, the sunaudio (or SADA) interfaces are still used.  You can only test 
this if you are using Solaris 11 or later, on a machine with a sound card 
supported by OSS.

I would say this is really more of a bugfix.  The main problem is that the 
configure script was avoiding even trying to build the OSS module on Solaris, 
and that the code only builds if the ioctls unsupported on Solaris are 
#ifdef'ed out on Solaris.  So it would make sense to support the ability to 
build the OSS module in 2.7, 3.x and onwards.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue16902] Add OSS module support for Solaris

2013-01-09 Thread brian-cameron-oracle

brian-cameron-oracle added the comment:

Correct, OSS should work out-of-the-box on Solaris 11 and up since it is
the default audio system there.  OSS was also integrated into OpenSolaris, so 
it is probably the most sensible audio plugin to use there also.  Some 
end-users may build and install their own OSS code on Solaris 10 or earlier, so 
it should not hurt to try and build the OSS plugin even on older versions of 
Solaris. 

Also, I'm not sure if the way I'm doing the #ifndef's in the patch is right.  
Looking at the rest of the code, I see that each EXPORT_INT is
surrounded by its own #ifdef.  I added similar #ifdef's around 
SNDCTL_DSP_BIND_CHANNEL SNDCTL_DSP_MAPINBUF, and SNDCTL_DSP_MAPOUTBUF.
However I just put #ifndef __sun around the SNDCTL_COPR_* and
SNDCTL_DSP_* ioctls because it seemed to make the patch more simple.
But, I'm not sure this was the right decision.  Maybe it just might be
more consistent to use an #ifdef around each one separately.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue16902] Add OSS module support for Solaris

2013-01-09 Thread brian-cameron-oracle

brian-cameron-oracle added the comment:

Sure, doing multiple #ifdef's makes sense.  Do you need me to provide an 
updated patch, or is this something easier for someone who has commit access to 
the source code repository to just go ahead and do.

I would think this Module would fail to compile if OSS isn't present, no?  So I 
guess I do not understand your comment about this possibly causing any sort of 
crash on import at runtime.

The Modules/ossaudiodev.c file should not compile if 
/usr/include/sys/soundcard.h isn't available with OSS definitions.  It wouldn't 
be on Solaris 10 or earlier.  Is it okay to try and compile this plugin and let 
it fail if it does?  Or does the configure script need to check this first and 
only try building it on Solaris 11 or later?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue16902] Add OSS module support for Solaris

2013-01-09 Thread brian-cameron-oracle

brian-cameron-oracle added the comment:

I'm not sure how to write such OSS detection code.  I do know that
OSS is only on Solaris systems that have this OSS-specific file:

/usr/include/sys/soundcard.h

So that's probably the best way to check and it should work even on Solaris 10 
if OSS is already installed by the end-user.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com