[Stk] Improving support for iOS

[Stephen Sinclair]

On Wed, Sep 25, 2013 at 4:10 PM, Felipe Sateler <fsateler at gmail.com> wrote:
> On Wed, Sep 25, 2013 at 10:00 AM, Stephen Sinclair
> <sinclair at music.mcgill.ca> wrote:
>> Hello all,
>>
>> Okay I have re-written my master branch to reflect all previous releases of STK.
>>
>> https://github.com/radarsat1/stk/commits/master
>>
>> This can become the new STK master branch if you think it is good.
>
> I've submitted a few patches we carry in debian as pull requests :)
>
> We do carry some more but they should probably be fixed up a bit
> before inclusion. (Mostly build system cleanup stuff, the curious can
> look at what we carry at
> http://patch-tracker.debian.org/package/stk/4.4.4-3)

I think the patches you've submitted so far are good.  However, I'll
wait to merge any external pull requests until we've agree that the
master branch isn't going to be further rewritten.

As for your 'install target' patch, it's a good idea, but I'm
wondering how much work it would be to actually just move to
automake/libtool.  Although, I'm also equally in favour of *not*
modifying the build system too much, to keep things simple.  I might
work on automake support in a branch just to see how it goes.

On another subject, as the Debian guy, I'm curious about your thoughts
on RtAudio's multiple back-ends.  I imagine that if you compile it
simultaneously for ALSA, Jack, OSS and Pulse, then the RtAudio package
would have to have dependencies on all of these, which can't be very
convenient.  What would a good solution be?  I suppose ideally you
would have separate packages, e.g rtaudio-jack, rtaudio-alsa, etc.,
but then dynamic backend loading/selection would need to be supported
at run-time.

Which sounds great, but drastically breaks RtAudio's approach to
simplicity -- i.e., embedding a single .cpp file in your project to
automagically have a wide range of audio compatibility.  I've thought
about this problem somewhat but not yet come up with a good solution
to propose.

Steve