4 ms·

Would you write an article detailing your experience? It sounds fun to read.

by Shorel 10y ago

ryandrake 10y ago
Honestly, I don't think I could afford the therapy that I would need to re-live that part of my career in the detail that it would take to do a proper write-up. To this day, I still have no idea how an Android project actually winds up getting built, and their build system philosophy seems to boil down to "keep adding layers of magic, each making lower levels of magic harder to hand-edit and understand". Most of the difficulty to be honest was with: 1. third party libraries, and 2 the Android NDK. For third party libraries, every one was slightly different in some frustrating way. Some of them used bog-standard makefiles (thank you, third party developers who do this!), so they basically just worked. Some of them used autoconf/automake, which makes me sad but you can generally get cmake to mate successfully with them. Some of them helpfully had their own CMakeLists.txt, which would build the library, but invariably could never be successfully integrated into a larger project. Some non-open-source libraries came with just one platform's build support, so you'd have to hand-build CMake support for them, and guess which files actually needed to be built/linked. Some of them cleverly generated some of their own source files during the build process ("This is fun to maintain" said nobody ever). The Android NDK seems to be some Googler's frankenstein hobby project that got accidentally electrified into life and set loose on the world. Like Donald Trump, the NDK is kind of an embarrassing offshoot from the "mainstream Android development story," one that Google would like to pretend doesn't exists. They, in fact, tell you in their docs "Yea, you can use native C and C++ to write Android apps with this thing, but you really shouldn't!" [1] Seriously, their "Getting Started" guide spends a paragraph or so trying to convince you not to get started. Convincing Google's own development tools to build C++/NDK is pretty frustrating itself, so you can imagine how difficult it is to convince cmake to do it. In short, if you are working on a project that targets desktop, embedded, and mobile platforms and has lots of third party code, and one day that little voice in your head starts saying "Hey we waste a lot of time maintaining separate Makefile, .xcodeproj, .vcproj, etc. Why don't we switch to a single glorious build system that lets us list our source files in one place!?" IGNORE THAT VOICE. Go play some foosball, fix a few bugs, have a cup of coffee, but by no means try to use cmake for this. 1: https://developer.android.com/ndk/guides/index.html https://developer.android.com/ndk/guides/index.html
- Shorel 10y ago
  Absolutely crazy. Thanks for the write up.
- bschwindHN 10y ago
  I've had a similar experience getting shit to work on multiple platforms. I decided not to use cmake for mobile targets. While the NDK in general sucks to build, if you follow certain patterns you can get a system that works and is fairly straightforward. The path to get there is not easy though, I'll give you that.

Would you write an article detailing your experience? It sounds fun to read.

by Shorel 10y ago

Would you write an article detailing your experience? It sounds fun to read.

Honestly, I don't think I could afford the therapy that I would need to re-live that part of my career in the detail that it would take to do a proper write-up. To this day, I still have no idea how an Android project actually winds up getting built, and their build system philosophy seems to boil down to "keep adding layers of magic, each making lower levels of magic harder to hand-edit and understand". Most of the difficulty to be honest was with: 1. third party libraries, and 2 the Android NDK. For third party libraries, every one was slightly different in some frustrating way. Some of them used bog-standard makefiles (thank you, third party developers who do this!), so they basically just worked. Some of them used autoconf/automake, which makes me sad but you can generally get cmake to mate successfully with them. Some of them helpfully had their own CMakeLists.txt, which would build the library, but invariably could never be successfully integrated into a larger project. Some non-open-source libraries came with just one platform's build support, so you'd have to hand-build CMake support for them, and guess which files actually needed to be built/linked. Some of them cleverly generated some of their own source files during the build process ("This is fun to maintain" said nobody ever). The Android NDK seems to be some Googler's frankenstein hobby project that got accidentally electrified into life and set loose on the world. Like Donald Trump, the NDK is kind of an embarrassing offshoot from the "mainstream Android development story," one that Google would like to pretend doesn't exists. They, in fact, tell you in their docs "Yea, you can use native C and C++ to write Android apps with this thing, but you really shouldn't!" [1] Seriously, their "Getting Started" guide spends a paragraph or so trying to convince you not to get started. Convincing Google's own development tools to build C++/NDK is pretty frustrating itself, so you can imagine how difficult it is to convince cmake to do it. In short, if you are working on a project that targets desktop, embedded, and mobile platforms and has lots of third party code, and one day that little voice in your head starts saying "Hey we waste a lot of time maintaining separate Makefile, .xcodeproj, .vcproj, etc. Why don't we switch to a single glorious build system that lets us list our source files in one place!?" IGNORE THAT VOICE. Go play some foosball, fix a few bugs, have a cup of coffee, but by no means try to use cmake for this. 1: https://developer.android.com/ndk/guides/index.html https://developer.android.com/ndk/guides/index.html

Shorel 10y ago
Absolutely crazy. Thanks for the write up.
bschwindHN 10y ago
I've had a similar experience getting shit to work on multiple platforms. I decided not to use cmake for mobile targets. While the NDK in general sucks to build, if you follow certain patterns you can get a system that works and is fairly straightforward. The path to get there is not easy though, I'll give you that.