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?

Brian, is this supported in Solaris 10 or Solaris 11?.

How can I actually try it?. I use Solaris on servers, and have Solaris 10/11 virtual machines in my laptop but never ever used sound under Solaris...

Also, I am unsure about this being a new feature (available in future Python 3.4) or a bugfix (to be available on 2.7, 3.2, 3.3 and 3.4). Opinions?

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.

Brian, then this module should be compiled only under Solaris 11 and up and, presumably, OpenSolaris/Illumos derivatives.

Does your patch compiles cleanly under previous Solaris versions?.

I am +1 to consider this a bugfix. Any other python-dev opinion?

PS: My virtual machines are configured with AC97 sound. Is that supported under Solaris 11?.

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.

The problem with your approach is that different Solaris release could support different flags. So I rather prefer specific #ifdef's.

I wonder about compiling OSS module under Solaris without OSS support. Compiling a module acting as "NULL" is OK, compiling a node that will crash on import, for instance, it is not.

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?

Brian, this patch would try to compile OSS module on any Solaris machine, even if not OSS support is provided. That is, compilation would fail in that case. That is not acceptable. Some kind of OSS detection is needed.

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.

Brian, Linux has that include file too. So, yes, I think that detection would be appropiate. If we could confirm that all platforms with OSS support have that file, we could have something :-).

If not, or we are not sure, just check for that file *IF* the platform is "sunos5.

Could you possibly provide a new patch with that test and independent #ifdef's?

I am assigning this issue to me. Lets move :-).

For user installed packages, the usual path would be "/usr/local/include/sys/soundcard.h". So, maybe check both paths. Do you agree?

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?

For what it's worth, I've been using a patch nearly identical to this one with python 2.6.x and 2.7.x with good success, and in my case it was under Solaris 10 with the no-cost "oss" package from 4Front.  I now have a new workstation and I've installed OpenIndiana (one of the OpenSolaris derivatives) on it, so I've had to revisit my patch slightly to get it to work with Python 2.7.5.

It causes no real harm to attempt to build ossaudiodev even on earlier Solaris platforms that don't have the package installed.  With Brian's patch or mine, the build reports that it expected to build ossaudiodev but that build failed.  There are other modules that setup.py expects to have work on Solaris that do not, so this is not the first instance of trying something only to have it gracefully fail.  It's really no different from what's being done with linux -- setup.py attempts to build ossaudiodev for all Linux distributions, even though some of them have ripped out support for OSS, in favor of ALSA or Pulse.

I would agree that using individual ifdef's for each define is useful; it appears that the oss package from 4Front provides more of the defines than the modified "Boomer" OSS headers that are part of the OpenSolaris derivatives.

My recommendation would be that Brian's patch or something like it be included as a bug fix in any releases of Python, not as just a "new feature" in the latest release.

Sooo....  It's been 3 years.  Brian's patch has bit-rotted a bit, but it's easy to update for recent Python.

What are the hold-ups to getting this applied?

This patch has also been applied to the python versions shipped by OpenIndiana and OmniOS for a long time. I'd say it's safe to merge.