Repopulating icedtea.classpath.org/hg/pulseaudio (was Re: RFC: PR1050 - Stream objects not garbage collected?)

[Omair Majid]

On 07/16/2012 04:40 AM, Andrew Hughes wrote:
>> Unlike icedtea-web, which runs standalone, we will need to modify
>> configure in icedtea{6,7,8} to accept paths to the built pulse-java
>> jar
>> and so so it can be integrated properly.
> 
> No, that's upside-down.  PulseAudio should be responsible for installing
> itself in a given JDK, just as IcedTea-Web is.  Otherwise, you end up
> with a potential recursive dependency (IcedTea needs the PulseAudio provider,
> which needs a JDK to be built).

I am not sure whether that's doable. IcedTea-Web uses a JDK, while this
provider has to be used by the JDK. The jar and the so need to be placed
in specific locations in the JDK tree for this to work.

I could add an install target that installs it into the JDK, but that
would limit it to one JDK at a time - when there's no reason it could
not be used by multiple JDKs (icedtea 6, 7 and 8) simultaneously.

Here's the approach I am considering: this provider will be installed
into a known location (say, /usr/lib/pulse-java). The patches to
icedtea{6,7,8} will modify the configure flag (--with-pulse-java) so the
path specified by it is picked up and symlinks to the jar and so are
placed in appropriate folders after icedtea is built. If the flag is
disables the provider, it is not looked for. So while the dependency
chain is there, there is a clear way to break it.

1. Build icedtea7:
./configure --with-pulse-java=no
make
<do equivalent of make install>

2. Build pulse-java:
./configure
make
make install

3. Build icedtea7:
./configure --with-pulse-java=/path/to/installed
make
<do equivalent of make install>

Step 1 is for bootstrapping and 2 and 3 can be skipped if that's all you
need.

Thoughts?

Thanks,
Omair