[Stk] iOS static library

[Richard Dobson]

On 10/03/2014 01:42, Ariel Elkin wrote:
..
>>>
The oldest standard which will compile STK (c89?)? But this only matters
>> if you are trying to distribute a binary library. This might be a
>> bit on the generous side!
>
> So if I understood you correctly you’d recommend C89? What do you
> mean by it being on the generous side?
>

Deciding on a C/C++ standard only matters if you are aiming to 
distribute a pre-compiled binary library. That is what I suggested was 
on the generous side. And, I would also suggest, unnecessary. Stk is 
distributed in source form, and the developer will naturally use 
whatever compiler standard suits their project, and matches what their 
version of Xcode can support. I don't "recommend" C89, I was just 
speculating on whether Stk would build under C89. The more you poke 
around making decisions on behalf of developers, the more they have to 
poke around finding out what they are and maybe changing them again. 
Write a README file instead!


>>
>>
..
>>
>> In any case one must assume that developers will want to [be able
>> to] tweak the contents of rawwaves as their app requires - whether
>> by removing unneeded waveforms or by adding other custom ones. So
>> the rawwaves folder should not built into the library itself.
>
> That sort of developer indeed won’t require or use a rawwaves bundle.
> But I honestly believe that most iOS developers out there, especially
> if new to the STK or DSP, will just want to use, say, Mandolin, Moog,
> or Rhodey, out of the box; so why force them to manually add each raw
> wave required for that? Other people already observed that it’s best
> to build everything rather than requiring developers to manually
> figure out all the STK files’ dependencies. The way I’m building the
> static library is so that copying the rawwaves bundle is required
> only if you’re using a class that uses them, and even then it’s just
> an extra 282KB.

I think you are trying to hand-hold developers too much. It is 
(relatively speaking) the simplest of things to add the library binary 
to an Xcode project (along with whatever other libraries they may happen 
to need), and the most that would be needed would be a tiny bit of extra 
documentation to that effect (that README file). Absolutely no need to 
embed it in any library code, and certainly no need to modify any of the 
STk code itself. The Stk may (as a library) be relatively unusual in 
making use of an "external" folder containing sample files, but I think 
that is reasonably clear in the existing documentation. They have to 
manage this generally, not only when developing for iOS.


..
> But adding #include <CoreFoundation/CoreFoundation.h>
>
> to Stk.cpp elicits several errors in Core Foundation itself… So, any
> ideas on how can I make use of Core Foundation types in Stk.cpp?
>

I think this is a wrong route to follow, and in the present context 
unnecessary.

Richard Dobson