MSYS is Not MinGW
On Wed, Jun 11, 2014 at 5:16 PM, Eric Wing <[email protected]> wrote: > 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
