[CMake] Cygwin drive paths are killing me

[Eric Wing]

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/