Allowing for more flexibility for iOS building

[mobileben]

So I've done an update after a couple of months since my last update. There have been some changes to how iOS builds ... and these changes are definitely for the better.

There are a couple of things I'd like to see adjusted for flexibility.

• I typically use static libs not frameworks. I had previously added support for this. If you look at cpprest_find_boost.cmake, one can see it looks for either a static or framework. I'd like to see configure.sh adjusted for this. Something like:

if [ ! -e $ABS_PATH/boost.framework ] && [ ! -d $ABS_PATH/boost ]; then

If we want more explicit, it can be changed to something like openssl is doing and keying in on a specific lib like boost/lib/libboost_system.a.

• It would be nice to be able to change the min deployment version. Right now it is locked on 8.0 due to the dependency with ios.toolchain.cmake.

• It would be nice to have a means to only configure, not make.

• It would be nice for build.XYZ.ios to have the include and lib directory. Where the lib would contain libcppestsdk.a and the include would contain all necessary includes. More or less it is like we "installed" it into build.XYZ.ios. This makes it easier to move and integrate to where ever you need to.

[BillyONeal]

Hello @mobileben -- are you interested in making a PR with these changes? I/we don't actually know anything about iOS and only made changes in an attempt to make builds work in Azure Pipelines to make sure we don't egregiously break iOS builds on you in the future. (e.g. you mention about "static or a framework" but I don't know what a framework is.... ;) )

[mobileben]

@BillyONeal sure, let me take a look. I already did one of them in my fork.

[mobileben]

@BillyONeal does Azure rely on the final location of the library? Currently it is written to

Build_iOS/build.Release.ios/libcpprest.a

I want to move it to Build_iOS/build.Release.ios/lib/libcpprest.a so I can also copy the include files to Build_iOS/build.Release.ios/include

[BillyONeal]

Nope, it doesn’t care; go for it

[mobileben]

👍 Cool, I'll be submitting a PR soon. I added some more items to it ... admittedly it is a bit catered to what I need, but it's possible others can use it too. It just lets you configure the underlying ios.toolchain.cmake from configure.sh.

I'm testing it right now. The default (no args) should behave like it originally did, minus being written to different locations.

[BillyONeal]

At the moment you may be the only person using that so being catered to what you need is actually good (since the point here is to not break you)

[BillyONeal]

Also feel free to create a PR just for the sake of running the tests :)

[mobileben]

@BillyONeal I just created the PR. I am updating a copy I made of the Wiki so we can put the changes I made in the iOS instructions.

Feel free to let me know what you want me to fix. I'm more than happy to change any approach I employed ... just need to "preserve" the net results.

[BillyONeal]

PR merged, thanks again!