Improve the build script for iOS

[bassosimone]

1. make sure that this build script cross-compiles the library and all its dependencies for all the architectures supported by iOS (that is, both arm and x86 for the emulator)
2. make sure that running the build script one ends up with all the needed headers and libraries installed into the proper place
3. optionally (depending on how much this is complex and needed), in the previous step teach the build script to produce a .framework which is probably even easier to integrate

[hellais]

I would take a look at how openpeer distributes it's library for iOS and Android: http://openpeer.org

[bassosimone]

Ok, so @alessandro40, @AntonioLangiu and I have spent some time looking at openpeer.org.

Speaking of iOS specifically, they generate a framework using Xcode that one can download from their website. So the idea of trying to build a framework for libight is in line with what they do (whether to do this with Xcode or with a script is probably a matter of taste).

For Android, instead, they distribute an SDK containing Java classes that in turn reference code accessible through Java Native Interface and packages as a shared library.

More in general, looking at their work we come up with the following comments:

1. Compared to us, they have a more modular and better organized build system. Like us, they use subrepositories for dependencies. In some cases such subrepositories only contain scripts to download a specific version of a library and build it; see for example the repository of their boost library, which only contains scripts to download and compile boost. Note that they have their own fork of their dependencies, which probably is good because it allows one to appply occasional tweaks.

We like it when they compile a library using its own build system. We probably should do the same in libight, rather than forcing the GNU autotools model to everything. For example, we should have a high-level script that invokes yaml-cpp build system rather than rolling out our own include.am to build yaml-cpp using autotools. To be fair, there are also cases in which they override the build system of a library with another one, which increases maintainance burden if you have to maintain your custom build system for a libray. If we want to structure more clearly our build system, here we sketched up how it could possibly look like.

One thing that I specifically am not comfortable with is that they download library sources using plain http in some cases. If we go down that road, I'd rather download using https, verify the digital signature, or clone the repository from github using https.

2. They have implemented wrappers for ObjC and Java that programmers could use. In doing this, we think they tried the least surprising solution for programmers of such platform.

For Android, one cannot avoid to do something like this, since Java code must be interfaced in some way to C++ code. For iOS, there is the option of using C++ code from ObjC++, which is what we currently do (and maybe that's a good thing since we're quite early in the development of libight and so adding API glue at this stage might not be wise).

Anyway, just for the sake of reasoning about this (and given that it's unavoidable to make a wrapper for Java), we have sketched up a possible simplified C++ API and its possible interfaces in Java and ObjC.

Speaking of Java, they used javah to generate header files from a Java interface. Then, they apparently wrote at hand glue code. It is worth mentioning that we can also use the simplified wrappers and interface generator to do this task, if the cost of writing and maintaining the glue API seems high. In any case, I specifically think it would be sensible to expose a thin API, because this reduces the chances that something can go wrong.

[bassosimone]

Updates with respect to this (with impact also on #85):

1. I've started to sketch out a repository for building libight as a reusable dependency for iOS applications.

2. I've also created a simple iOS application that uses the above repository.

3. I've discussed with @hellais the possibility of putting the compile-time dependencies in one or more digitally signed tarballs, created from cloned git repositories, and downloadable during the build process from OONI's website. This should allow to solve the following issues:

   3.1. that to compile libight you need to clone (as opposed to download) projects with large history.

   3.2. that some projects do not provide digitally signed tarballs.

[bassosimone]

With respect to the above update, I've moved and expanded item 3 of the list into issue #98 since I do not think it's priority to do this sort of stuff before libight-1.0.0-release.

Therefore, to close this specific issue what remains to be done is to:

• review, discuss and hopefully merge the following two pull requests:
  • Make embedders job simple #90 that allows a driver build script to compile and install libight (and all its dependencies) headers and library at a fixed location (this is already used by the new build repository for ios)
  • Remove unused build ios.sh #94 that removes build_ios.sh a copy of which exists in the new build repository for ios
• reason a bit more on the interesting stuff documented above with respect to openpeer and open a set of issues for libight from it proposing improvements

[bassosimone]

Guess we can close this issue by now, keeping in mind that openpeer could always be an useful reference when we're in doubt.