Headers and libs are often located in a usr directory ( usr/include and usr/lib). The compiler tools usually reside in a bin subdirectory, and are called gcc and g++, or in the LLVM world: clang and clang++, sometimes the tools also have a prefix: pnacl-clang and pnacl-clang++), or they have completely different names (like emcc in the emscripten SDK). But lets start at the beginning:Ī cross-compiling scenario is normally well defined in the GCC/cmake world:Ī toolchain wraps the target-platform’s compiler tools, system headers and libs under a standardized directory structure: Now, what I want to do with my shiny new Nexus7 is of course this: >. This also works on Windows (32- or 64-bit): > oryol build win64 - vstudio - debug oryol build emscripten - make - release Or to build Oryol for emscripten with make in Release mode (provided the emscripten SDK has been installed): >. Or to perform a command line build with xcodebuild instead: >. The front-end python script called ‘oryol’ is used to juggle all the build-configs, invoke cmake with the right options, and perform command line builds. osx-xcode-debug, win32-vstudio-release, emscripten-make-debug, …). A build-config is one specific combination of target-platform (osx, ios, win32, win64, …), build-tools (make, ninja, Visual Studio, Xcode, …) and compile-mode (Release, Debug) stored under a descriptive name (e.g. The Oryol build system is cmake-based, with a python script on top which simplifies managing the dozens of possible build-configs. Ok, so the logical next step would be to add support for Android to the Oryol build system (if you don’t know what Oryol is: it’s a new experimental C++11 multi-plat engine I started a couple months ago: ). The UI finally feels completely smooth, and I didn’t have any of those Windows8-Metro-style WTF-moments yet. It basically went like this “hey that looks quite neat for a non-iPad tablet => wow, scrolling feels smooth, very non-Android-like => holy shit it runs my Oryol WebGL samples at 60fps => hmm 179 Euros seems quite reasonable…” - I must say I’m impressed how far the Android “user experience” has come since I last dabbled with it. This wasn’t exactly on my to-do list until I sorta “impulse-bought” a Nexus7 tablet last Thursday. I’ve spent the last 2.5 days adding Android support to Oryol’s build system. I’ll keep an eye on that and update the blog post with my findings. I noticed that I didn’t set a library search path to the toolchain lib dir in the linker step (-L…) which might explain the crash I had earlier, but unfortunately I can’t reproduce this crash anymore with the old behaviour (no library search path and no shared system libraries in the APK). Update: Thanks to thp for pointing out a rather serious bug: packaging the standard shared libraries into the APK should NOT be necessary since these are pre-installed on the device. TL DR: how to build Android NDK applications with cmake instead of the custom NDK build system, this is useful for projects which already use cmake to create multiplatform/cross-compiling build files.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |