<div dir="ltr">Sorry for double posting...<div><br></div><div>This is my simple toolchain ; it would need option variables to replace armeabi with x86 in places... it's not that long or complex; and could match environment variables slightly better...</div>
<div><br></div><div><a href="https://code.google.com/p/c-system-abstraction-component-gui/source/browse/a2_toolchain.txt">https://code.google.com/p/c-system-abstraction-component-gui/source/browse/a2_toolchain.txt</a><br>
</div><div><br></div><div>The last lines of this (97-113) </div><div><a href="https://code.google.com/p/c-system-abstraction-component-gui/source/browse/android_build/core.puregl2/CMakeLists.txt">https://code.google.com/p/c-system-abstraction-component-gui/source/browse/android_build/core.puregl2/CMakeLists.txt</a><br>
</div><div><br></div><div>generate targets that current cmake will complain about called 'package' 'install' and 'uninstall' which is what the real work of ndk-build does...</div><div><br></div><div>
The nastiness above the last lines copies from an 'installed' built target... like I do a build into ../build/debug_build and install into .../build/debug_out ... and copy from the debug_out to .../debug_package/project... the appropriate parts... which it shoulds like you have already.</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 11, 2014 at 5:16 PM, Eric Wing <span dir="ltr"><<a href="mailto:ewmailing@gmail.com" target="_blank">ewmailing@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, I will probably try MSYS next. Then I will see if I can remove<br>
MSYS entirely. (Though I'll need to rewrite my helper script which is<br>
mostly Perl.) I'll look into that standalone Make 3.8.1.<br>
<br>
The helper script basically does the CMake generation 3 times<br>
(armeabi, armeabi-v7a, x86). The script has conventions and smarts to<br>
find my 3rd party libraries and where the per-arch subdirectories.<br>
This sets variables which are passed to CMake and used in the -C<br>
initial_cache so everything is automatically configured in one shot.<br>
<br>
The other trick/pitfall is that CMake also manages the resources (to<br>
make sure they get put in the right place to be bundled in the apk).<br>
This has several tricky consequences...first, since CMake is run 3<br>
times, each build instance reproduces (wastes) this work. This also<br>
means there is a layer of indirection because there needs to be a<br>
"real" common build directory that is shared/common to the<br>
per-architecture build instance directories, so additional variables<br>
are passed through CMake to alert these build stages where they need<br>
to copy the assets too. Copying the libs also has to be aware of this<br>
plus making sure to place it in the correct architecture subdirectory<br>
to avoid clobbering.<br>
<br>
There are additional details the build process needs to handle. The<br>
goal is to make this almost turn-key/automatic, as if this is what<br>
CMake should already be doing. (I do plan to share my scripts/results<br>
once I'm done hoping we can figure out how to make CMake do all this<br>
natively.) But this is why it's not quite so trivial.<br>
<br>
<br>
I use the standalone toolchain because I couldn't get the<br>
Android-CMake toolchain to work with the regular NDK. I was under the<br>
impression it may have worked in r7 or maybe earlier, but it's now r9d<br>
and that's a really long time ago (like over 10 releases).<br>
Additionally, I am most on Mac, but need to support Mac, Linux, and<br>
Windows. I think the existing toolchain did not understand Mac well.<br>
<br>
Additionally, I had to audit it and a lot of the flags the chain was<br>
passing did not match the real NDK, so I fixed most of them, but only<br>
tested on the standalone since it was the only one working. Also, x86<br>
was really weak or non-existent so I had to do a bunch of stuff for<br>
that.<br>
<br>
And I don't yet understand how the regular toolchain deals with the<br>
different C++ standard libraries that can be selected. I have had to<br>
interoperate with other prebuilt binaries and have been slammed hard<br>
on all the C++ unstable/incompatible ABI issues which Android has made<br>
into a minefield.<br>
<br>
I would love to ditch the standalone toolchain, but unless I can get<br>
one that actually works and that I can trust is doing the right thing,<br>
I'm stuck. (I did try fixing it, but that is a really complicated<br>
script.)<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Thanks,<br>
Eric<br>
--<br>
Beginning iPhone Games Development<br>
<a href="http://playcontrol.net/iphonegamebook/" target="_blank">http://playcontrol.net/iphonegamebook/</a><br>
</div></div></blockquote></div><br></div>