Hi Robert,
I’ve been struggling with the same thing. My cross-platform build already uses
a combination of CMake and Gradle, which enables IDE integration on all
supported platforms except Android. When I started this project about 3 years
ago, there weren’t any real options for native code development on Android
inside an IDE, so I initially went down the same Ant/Eclipse path as you,
running separate commands to build the native portions via CMake and putting
the .so files into the right place so Eclipse would find them. Even managed to
get debugging to work with a little coaxing.
Fast forward a couple of years and Google has completely abandoned Ant+Eclipse,
so my custom workflow is now outdated. There is now also an explosion of
options for working with C++ code on Android, including:
• A first-party plug-in for Visual Studio from Microsoft;
• VisualGDB;
• WinGDB;
• Gradle’s own C/C++ support via its Native Build System;
• Google’s own CMake support via Android Studio
• JetBrains CLion
I spoke to a few people at Google when I was at I/O this year, and I got the
general impression that CMake+Gradle+Android Studio is only going to work if
you’re targeting Android exclusively. If you want to continue targeting
multiple platforms, you’re still kind of on your own, and your experience with
their custom version of CMake supports that impression.
I haven’t had time to explore all of the options I listed above to try to
figure out which would provide the best workflow, but my general sense is that
Android Studio needs to continue to treat your CMake build as a black box.
Fortunately, there are a lot of extension points with the Gradle-based build
that underpins all Android Studio projects, so you can effectively create
pre-build steps that will essentially cmake –build your native code and drop
the .so files into the right place, before proceeding with the managed code
Android toolchain. From there, it should be possible to attach Android Studio’s
managed code and native code debuggers to your running app, to concurrently
debug both sides.
At this point, I’ve probably strayed too far from the intent of this mailing
list, but I’m happy to discuss further with you offline.
Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410
Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309
On 10/25/16, 9:48 AM, "CMake on behalf of Robert Dailey"
<cmake-boun...@cmake.org on behalf of rcdailey.li...@gmail.com> 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
--
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
