It's my experience which maybe help. I love Android Studio for its jetbrains style coding experience, but with some bad style I don't like, like so frequency update and so many experiment feature which sometimes is a good part like CMake support!
I just love coding and focus my project, but the none product ready feature make me must fix some ide problem, SDK problem, config problem is really bad! So I use CLion to do most c++ related idea test which is mainly focus c++ native part, and test mix program in a simple java program, all the technology I use is CMake with CMake Swig support and CMake Java support which works well in CLion After the c++ part test is finish, I rewrite some code( mostly just copy from clion project) in Android Studio(this make c++ related works easy in the c++ unfriendly support environment), and then focus on java side. If c++ part has problem I will reenter the workflow to test idea in CLion again. My current working android project use CMake with CMake Swig support, it's really works great! Hope this help:) 2016-11-01 21:38 GMT+08:00 Robert Dailey <rcdailey.li...@gmail.com>: > Florent, I had the same thoughts. It seems that the CMake generate + > build step happen silently as a prerequisite step when doing the > 'gradle build' command somewhere. It makes it appear as if CMake is > not running at all, but instead the Java piece of the build is just > taking forever. > > Really I want to get away from ant / eclipse, but unlike Android > Studio, at least in Eclipse I can view C++ code and edit it. I don't > know of any other IDE I can use to edit both java & android code. My > last shining hope is perhaps Visual Studio 2015 and their Android > support. They have a fork of the CMake repository with some changes > for generating Android IDE projects for VS, I have not tried it > though. > > What a giant mess this has become... I have no idea what direction to > go on this. Advice on tooling combinations you guys are using would be > very helpful though. > > On Mon, Oct 31, 2016 at 5:04 PM, Florent Castelli > <florent.caste...@gmail.com> wrote: >> I tried the Gradle + CMake integration and I'm not really impressed. >> I would recommend not using it right now until they fix the rough edges. >> >> The prime concern is that it is REALLY hard to get the CMake output and >> compilation output, >> even within Android Studio. If you compile from command line, you won't see >> much. >> This is a no go for CI environments where you need to see what went wrong >> and also some >> output once in a while (or builds are usually considered stuck and canceled >> if they take too long). >> See the issue: https://code.google.com/p/android/issues/detail?id=210930 >> >> Installing CMake within the SDK is not trivial. There's an open bug with a >> proposed solution, >> it's not pretty stuff but does the work: >> https://code.google.com/p/android/issues/detail?id=221907 >> An alternative would be to repackage your SDK folder after running Android >> Studio and installing >> everything you need and distribute that to your CI build machines / >> developer machines. >> >> But essentially, what you want is probably just use their toolchain file, >> which is much better >> than the OpenCV one. You can find it bundled in the latest NDK and I guess >> you could be using >> that directly with CMake. If it is doing weird things, I guess you could >> have a look at it and debug it. >> It's not as complicated as the OpenCV one and I hope you'll find the >> solution to your issues! >> >> As for CMake 3.7, when I asked about it in this mailing list, someone said >> there will be >> a compatibility layer to the toolchain to reuse the upstream support when >> it's available >> if I remember correctly. >> >> /Florent >> >> >> On 25/10/2016 15:48, Robert Dailey wrote: >>> >>> I'm not sure if the CMake mailing lists are the right place to ask >>> this question but I thought I'd ask just in case someone has gone down >>> this path or has experience with what Google/Gradle is actually trying >>> to accomplish with what seems to be a hand-built version of CMake with >>> custom patches that are not in upstream repositories. >>> >>> Prior to switching to Android Studio / Gradle, I was using Eclipse / >>> Ant. The way I did CMake integration was not really integration at >>> all: I generated Ninja build scripts using CMake and implemented >>> custom targets to run "ant release" after all the C++ projects were >>> built. I made sure that CMake copied relevant *.so files to >>> appropriate directories in the Ant structure so they are packaged with >>> built APKs. That's how I did my Android development. >>> >>> Now that I'm integrating CMake into Gradle, first annoyance I noticed >>> is that I can't use CMake 3.7 (or any external installation of CMake) >>> with Android Studio. It requires a version of CMake installed through >>> SDK Manager. This means I can't use the new Android toolchain >>> functionality built into CMake 3.7 (sad face). But this is something I >>> can work around... >>> >>> Next I found out that stuff I'm setting in my CMake scripts, such as >>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied. >>> For whatever reason, Gradle is overriding these from the command line >>> (I'm guessing?). So this requires me to duplicate the toolchain / >>> compiler flag setup I already do in my CMake scripts now in the Gradle >>> build scripts. This seems completely unnecessary and a maintenance >>> burden. >>> >>> What I was expecting Gradle to do was essentially provide me some >>> toolchain file so that CMake can find the compiler and linker to use >>> and then the rest would be determined by CMake itself. >>> >>> Is there a way I can tell Gradle to not take so much control over >>> compiler flags? I want my CMake scripts to do this. I can't imagine >>> they had a good reason to do this. What have others done in this >>> situation with their own Gradle + CMake integration? Looking for >>> advice here, since information is sparse, especially since the Android >>> Studio 2.2 CMake integration is relatively new stuff. >> >> >> > -- > > 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/mailman/listinfo/cmake-developers -- 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/mailman/listinfo/cmake-developers