Temporary readme:

Examples:

OSX:
  x64:
    ./configure --host=x86_64-apple-darwin # (defaults chosen)
  x86:
    ./configure --host=i386-apple-darwin

IOS:
  ./configure --host=arm-apple-darwin # (defaults chosen)
  ./configure --host=arm-apple-darwin --with-sdk=4.3 --prefix=home/foo/xbmc-deps

Android (the pathes are examples and have to match those of docs/READM.android):
  arm:
    ./configure --with-tarballs=/opt/xbmc-tarballs --host=arm-linux-androideabi --with-sdk-path=/opt/android-sdk-linux --with-ndk=/opt/android-ndk-r10d --with-toolchain=/opt/arm-linux-androideabi-4.8-vanilla/android-17 --prefix=/opt/xbmc-depends
  x86:
    ./configure --with-tarballs=/opt/xbmc-tarballs --host=i686-linux-android --with-sdk-path=/opt/android-sdk-linux --with-ndk=/opt/android-ndk-r10d --with-toolchain=/opt/x86-linux-4.8-vanilla/android-17 --prefix=/opt/xbmc-depends

  

Linux:
  ARM toolchain (codesourcery/lenaro/etc)
    ./configure --with-toolchain=/opt/toolchains/my-example-toolchain/  --prefix=/opt/xbmc-deps --host=arm-linux-gnueabi
  RASPBERRY-PI:
    PATH="/opt/rbp-dev/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin:$PATH" ./configure --with-platform=raspberry-pi --host=arm-linux-gnueabihf --prefix=/opt/xbmc-deps --with-tarballs=/opt/xbmc-tarballs --with-toolchain=/opt/rbp-dev/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/arm-bcm2708hardfp-linux-gnueabi/sysroot --with-firmware=/opt/rbp-dev/firmware --build=i686-linux

  Native toolchain
    ./configure --with-toolchain=/usr --prefix=/opt/xbmc-deps --host=x86_64-linux-gnu


Details:
  We build a native tools for platforms that do not have the native tools we need. OSX is
  the largest builder of native tools as there is not much present. No cmake, no autotools, etc.

  Cross compiling is a real pain is the rear :) Generally there are three forms,
    autotools (configure/make), cmake driven, and hand crafted makefile. In term
    of usage, 90 percent are autotools, followed by cmake and hand crafted makefiles.
    Some libs need patching, most do not. Lib versions are picked for a reason, be prepared
    for robust testing if you go bumping libs. Never commit bumps unless you have also done
    a complete distclean nuke of EVERYTHING and rebuild from scratch on ALL platforms.
    Epic fail if this is not tested.

  1) autotool driven tend to be simple PROVIDED the authors followed proper autotool format.
     Try with $(CONFIGURE) 1st, if problem, try adding $(AUTORECONF) -vif before the
     $(CONFIGURE). Some are do silly things and only a config.site can correct the errors.
     So watch for this in the config.site.in. config.site rules and this is the only way
     to handle bad autotool behavior.

  2) cmake driven tend to be simple, setup cmake flags right and go. On rare cases, you might
     need to diddle the native cmake setup.

  3) hand crafted Makefiles typically require manual sed tweeks or patching.

