Re: [cmake-developers] A goal for a simple Android toolchain file.
Eric Wing wrote: I'm thinking it will probably be two weeks before I get back to Android. (If things go really well, maybe late next week.) Sounds good. I'd like to start by syncing up on a simple hello world executable and iterating toward the complex stuff. Can we chat on IRC to get on the same page? Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A goal for a simple Android toolchain file.
On 03/27/2014 11:09 PM, Eric Wing wrote:
One other issue I would like to see fixed is that it is impossible to
change some of the settings like architecture after the first
generation. I find that this makes the CMake GUI interface completely
useless to me and I always have to load up all my parameters up front
on the command line.
On the first Configure in a new build tree the cmake-gui pops up
a dialog to select settings for the toolchain to use. That could
be taught to be sufficient for selecting such information prior
to the first configuration if it is not already.
Though, one other consideration is maintainability. Android keeps
changing version numbers and moving/breaking things.
The upstream Android NDK folks may be open to distributing files
that are CMake-aware with the NDK. Then one could have a toolchain
file that does include(${ANDROID_NDK_ROOT}/.../toolchains.cmake)
to get information without scanning or globbing. What kind of
info would NDK-provided files need to have to be most useful?
Or, perhaps the NDK could actually provide the toolchain files.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A goal for a simple Android toolchain file.
Eric Wing wrote: I expect so, but knowing what the needs are helps inform what those changes might look like. http://public.kitware.com/Bug/view.php?id=14539 I'm not sure either. I recall an old thread about this That thread is presumably the first link in the bug report I linked. It does. Did you look at the Android.cmake I posted? I only skimmed it. You are far closer to Android development than me. I think more-useful than this discussion would be more-direct and active collaboration on code or code snippets, rather than skimming everything. That's why I posted the Android.cmake platform file. I have the feeling somehow that you only skimmed my initial mail. Do you have time/capacity for that collaboration? Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A goal for a simple Android toolchain file.
On 3/28/14, Stephen Kelly steve...@gmail.com wrote: Eric Wing wrote: I expect so, but knowing what the needs are helps inform what those changes might look like. http://public.kitware.com/Bug/view.php?id=14539 I'm not sure either. I recall an old thread about this That thread is presumably the first link in the bug report I linked. It does. Did you look at the Android.cmake I posted? I only skimmed it. You are far closer to Android development than me. I think more-useful than this discussion would be more-direct and active collaboration on code or code snippets, rather than skimming everything. That's why I posted the Android.cmake platform file. I have the feeling somehow that you only skimmed my initial mail. Do you have time/capacity for that collaboration? Yes, I am interested in collaboration. You caught me at an awkward time though. For the past year, I've been mostly handling various Android related disasters. I've been going insane, so I finally got a block of time to do everything/anything but Android (back to Mac, iOS, Linux. It can't all be rosy, so I'm being made to suffer with Windows, though the dose is small enough that its still better than Android). I'm thinking it will probably be two weeks before I get back to Android. (If things go really well, maybe late next week.) I've been meaning to try to figure out how to build SDL for Android using CMake. So maybe if you want to get a head start on what you are thinking for your toolchian and see how it works with SDL, that might be one possible way we can sync up and start collaborating. Or maybe simpler, try grabbing my ALmixer/HelloWorld project/documentation and build it using my current technique. Then see if you can make your toolchain handle it. Then we can sync up, I can try your toolchain, and start iterating on it. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A goal for a simple Android toolchain file.
On 3/26/14, Stephen Kelly steve...@gmail.com wrote: Eric Wing wrote: I have been using my fork of the Android-CMake (originally from OpenCV) that you want to obsolete. My fork contains a lot of fixes to deal with more recent NDK updates and more complicated requirements that I have. https://bitbucket.org/ewing/android-cmake It's great to have someone here who is both familiar with cmake and with Android! It is completely reliant on the Android standalone toolchain technique which I vastly dislike, Sorry, I don't know what you're referring to. What is a standalone toolchain? This: https://www.assembla.com/code/android-gb-for-sharp-is01/git/nodes/debug/ndk/docs/STANDALONE-TOOLCHAIN.html ? It looks like the primary usefulness of that is to avoid the caller having to specify the -sysroot. Do I misunderstand? With CMAKE_SYSROOT in CMake 3.0, and with the platform file I proposed, I don't see what makes that standalone toolchain stuff useful. Can you explain? Yes, I think that one. In the docs/ directory of the Android NDK you download, you can find the file: STANDALONE-TOOLCHAIN.html As I understand it, it basically copies selected things out of the Android NDK into another directory with a layout more consistent with typical distributions so you can more easily use 3rd party tools like CMake. Since Android overloads things like the architectures, the compiler, and the standard libraries, each permutation you care about must be copied out into a separate standalone toolchain instance. This is one of the things that is annoying about it; depending on Android NDK version, you may have 4 different compilers, each with 4 different C++ standard libraries (all of which are not necessarily compatible with each other). That means 4x4=16 permutations. If you want to distinguish between dynamic and static linking, then you may need to multiply by 2. Additionally, each architecture is a permutation, so you need to multiply another 2 or 3. Then if you can about specific ARM features not available on all chips (e.g. NEON), you add a bunch more for that. (The current Android-CMake toolchain seems to have some settings for those which I've mostly ignored so far.) Oh yeah, I think each API version needs its own standalone toolchain. It also looks like the latest Android NDK (r9d) made some additions/changes. https://developer.android.com/tools/sdk/ndk/index.html I think it is theoretically possible to invoke the Android build process without using the standalone toolchain, but the file/directory layout doesn't necessarily follow normal conventions. I think the original Android-CMake toolchain did support this, but somewhere around the 64-bit toolchain release, things broke pretty badly and I never got it to work. Android is free to re-arrange things and rename things and they seem to be emboldened to do so in the non-standalone toolchain. Additionally, because things are overloaded, you need to be very careful about not invoking the wrong options on the toolchain. I am mostly in middleware, so I need to build libraries that other people use. This means I am extremely sensitive to ABI issues and things like dynamic linking of C++ standard libraries or specific architecture optimizations that are not portable are huge no-no's and I need to trust what the toolchain is doing. There was also an alternative Android/CMake toolchain somebody wrote which I think didn't use the standalone toolchain and I tried to work with, but I started hitting a lot of the above problems which is what led me back to the more complicated OpenCV one. So while I'm not opposed to a brand new Android toolchain file, I want to assert that it needs to be correct and it does need to handle a variety of cases. So learn as much as you can from the existing ones. My aim is to put the things which should be in a Android.cmake platform file shipped with CMake into such a file. Some things belong in such a file, I think, and others belong in a toolchain file maintained externally. In my fork, I spent a lot of time re-reverse-engineering the standard/default Android flags passed to the compiler. OpenCV took too many liberties with changing what Android passes normally which resulted in unexpected/broken behavior for some of my other projects. I think a very conservative, deferential approach should be taken. If you can provide details, I think that would be useful. I wrote some comments in the changelog history in the comments of the file. My Mercurial history also has some stuff. There are too many details for me to remember. However, my general conclusion was try to match watch Android does by default (i.e. same flags). Another example is, I would defer to using the official stable compiler unless overridden. I think it is still gcc 4.6, not 4.8. I presume there is a reasoning behind the one they pick as the default/stable. I would also like it to understand multiple architectures which would also go a
Re: [cmake-developers] A goal for a simple Android toolchain file.
Eric Wing wrote: I have been using my fork of the Android-CMake (originally from OpenCV) that you want to obsolete. My fork contains a lot of fixes to deal with more recent NDK updates and more complicated requirements that I have. https://bitbucket.org/ewing/android-cmake It's great to have someone here who is both familiar with cmake and with Android! It is completely reliant on the Android standalone toolchain technique which I vastly dislike, Sorry, I don't know what you're referring to. What is a standalone toolchain? This: https://www.assembla.com/code/android-gb-for-sharp-is01/git/nodes/debug/ndk/docs/STANDALONE-TOOLCHAIN.html ? It looks like the primary usefulness of that is to avoid the caller having to specify the -sysroot. Do I misunderstand? With CMAKE_SYSROOT in CMake 3.0, and with the platform file I proposed, I don't see what makes that standalone toolchain stuff useful. Can you explain? So while I'm not opposed to a brand new Android toolchain file, I want to assert that it needs to be correct and it does need to handle a variety of cases. So learn as much as you can from the existing ones. My aim is to put the things which should be in a Android.cmake platform file shipped with CMake into such a file. Some things belong in such a file, I think, and others belong in a toolchain file maintained externally. In my fork, I spent a lot of time re-reverse-engineering the standard/default Android flags passed to the compiler. OpenCV took too many liberties with changing what Android passes normally which resulted in unexpected/broken behavior for some of my other projects. I think a very conservative, deferential approach should be taken. If you can provide details, I think that would be useful. I would also like it to understand multiple architectures which would also go a long way to simplifying the end-user experience, though I'm worried this might take deeper CMake changes. I expect so, but knowing what the needs are helps inform what those changes might look like. http://public.kitware.com/Bug/view.php?id=14539 set(ANDROID_SDK_ROOT /home/stephen/android/android-sdk-linux/) set(ANDROID_NDK_ROOT /home/stephen/android/android-ndk-r9/) It should also handle the semi-blessed/official Android environmental variables like ANDROID_SDK_ROOT and ANDROID_NDK_ROOT so you don't have to explicitly set them in CMake scripts. It does. Did you look at the Android.cmake I posted? set(ANDROID_NDK_PLATFORM android-18) It should automatically detect and use the latest Android target API if it is not explicitly specified. My Android.cmake also reads that from the environment. If there's a way to detect it automatically, that might be a good idea. Can you say how? Can you tell me for certain whether you looked at the Android.cmake file I linked to already? Knowing whether you did would help our discussion I think. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A goal for a simple Android toolchain file.
On 3/21/14, Stephen Kelly steve...@gmail.com wrote: Hi, I'd like it to be this easy to create an Android toolchain file: set(CMAKE_SYSTEM_NAME Android) set(ANDROID_SDK_ROOT /home/stephen/android/android-sdk-linux/) set(ANDROID_NDK_ROOT /home/stephen/android/android-ndk-r9/) set(ANDROID_NDK_PLATFORM android-18) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) In order to do that, more stuff would need to be in the Android.cmake platform file. The platform file I'm currently experimenting with is here: http://www.steveire.com/Android.cmake I would aim to obsolete the toolchain file which is commonly used for Android, which is here: http://code.google.com/p/android-cmake/source/browse/toolchain/android.toolchain.cmake I think part of the solution will need to be an interface in CMake for selecting an STL version. That will probably also be usable to select between libstdc++ and libc++ when using clang. Any comments on adding that kind of thing to the Android toolchain file? Thanks, Steve. I have been using my fork of the Android-CMake (originally from OpenCV) that you want to obsolete. My fork contains a lot of fixes to deal with more recent NDK updates and more complicated requirements that I have. https://bitbucket.org/ewing/android-cmake It is completely reliant on the Android standalone toolchain technique which I vastly dislike, but it works and does solve the problem of selecting between gcc 4.6, gcc 4.8, clang 3.3 (or whatever versions they have), as well as dealing with stlport, gnu libstdc++, clang libc++ and so forth. And I can at least brute force the multiple architecture builds (armv5, armv7, x86) with this technique. I am using it to build multiple projects, two of which I actually documented: ALmixer https://bitbucket.org/ewing/hello-android-almixer JavaScriptCore (this one is a nightmare to build correctly and I will be very unhappy with any new Android CMake toolchain that doesn't handle this.) https://github.com/appcelerator/hyperloop/wiki/Building-JavaScriptCore-for-Android So while I'm not opposed to a brand new Android toolchain file, I want to assert that it needs to be correct and it does need to handle a variety of cases. So learn as much as you can from the existing ones. In my fork, I spent a lot of time re-reverse-engineering the standard/default Android flags passed to the compiler. OpenCV took too many liberties with changing what Android passes normally which resulted in unexpected/broken behavior for some of my other projects. I think a very conservative, deferential approach should be taken. My wish list is that it would not require the standalone toolchain. This would go a long way to simplifying the end-user experience. I would also like it to understand multiple architectures which would also go a long way to simplifying the end-user experience, though I'm worried this might take deeper CMake changes. set(ANDROID_SDK_ROOT /home/stephen/android/android-sdk-linux/) set(ANDROID_NDK_ROOT /home/stephen/android/android-ndk-r9/) It should also handle the semi-blessed/official Android environmental variables like ANDROID_SDK_ROOT and ANDROID_NDK_ROOT so you don't have to explicitly set them in CMake scripts. set(ANDROID_NDK_PLATFORM android-18) It should automatically detect and use the latest Android target API if it is not explicitly specified. There also may need to be a setting to set the minSdkVersion, though that may fall outside of this since CMake is currently limited to deal only with the NDK side. I've ranted in multiple places about why the latest Android target API should be used. My most recent public post is here: https://forums.libsdl.org/viewtopic.php?p=42622sid=ce5cec7c0379740c39bd3819a914b99d Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] A goal for a simple Android toolchain file.
Hi, I'd like it to be this easy to create an Android toolchain file: set(CMAKE_SYSTEM_NAME Android) set(ANDROID_SDK_ROOT /home/stephen/android/android-sdk-linux/) set(ANDROID_NDK_ROOT /home/stephen/android/android-ndk-r9/) set(ANDROID_NDK_PLATFORM android-18) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) In order to do that, more stuff would need to be in the Android.cmake platform file. The platform file I'm currently experimenting with is here: http://www.steveire.com/Android.cmake I would aim to obsolete the toolchain file which is commonly used for Android, which is here: http://code.google.com/p/android-cmake/source/browse/toolchain/android.toolchain.cmake I think part of the solution will need to be an interface in CMake for selecting an STL version. That will probably also be usable to select between libstdc++ and libc++ when using clang. Any comments on adding that kind of thing to the Android toolchain file? Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
