[CMake] Cygwin drive paths are killing me

[J Decker]

MSYS is Not MinGW


On Wed, Jun 11, 2014 at 5:16 PM, Eric Wing <ewmailing at gmail.com> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20140611/6e13f98f/attachment.html>