Yes, I will probably try MSYS next. Then I will see if I can remove MSYS entirely. (Though I'll need to rewrite my helper script which is mostly Perl.) I'll look into that standalone Make 3.8.1.
The helper script basically does the CMake generation 3 times (armeabi, armeabi-v7a, x86). The script has conventions and smarts to find my 3rd party libraries and where the per-arch subdirectories. This sets variables which are passed to CMake and used in the -C initial_cache so everything is automatically configured in one shot. The other trick/pitfall is that CMake also manages the resources (to make sure they get put in the right place to be bundled in the apk). This has several tricky consequences...first, since CMake is run 3 times, each build instance reproduces (wastes) this work. This also means there is a layer of indirection because there needs to be a "real" common build directory that is shared/common to the per-architecture build instance directories, so additional variables are passed through CMake to alert these build stages where they need to copy the assets too. Copying the libs also has to be aware of this plus making sure to place it in the correct architecture subdirectory to avoid clobbering. There are additional details the build process needs to handle. The goal is to make this almost turn-key/automatic, as if this is what CMake should already be doing. (I do plan to share my scripts/results once I'm done hoping we can figure out how to make CMake do all this natively.) But this is why it's not quite so trivial. I use the standalone toolchain because I couldn't get the Android-CMake toolchain to work with the regular NDK. I was under the impression it may have worked in r7 or maybe earlier, but it's now r9d and that's a really long time ago (like over 10 releases). Additionally, I am most on Mac, but need to support Mac, Linux, and Windows. I think the existing toolchain did not understand Mac well. Additionally, I had to audit it and a lot of the flags the chain was passing did not match the real NDK, so I fixed most of them, but only tested on the standalone since it was the only one working. Also, x86 was really weak or non-existent so I had to do a bunch of stuff for that. And I don't yet understand how the regular toolchain deals with the different C++ standard libraries that can be selected. I have had to interoperate with other prebuilt binaries and have been slammed hard on all the C++ unstable/incompatible ABI issues which Android has made into a minefield. I would love to ditch the standalone toolchain, but unless I can get one that actually works and that I can trust is doing the right thing, I'm stuck. (I did try fixing it, but that is a really complicated script.) Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
