[CMake] CMake, Android, and Eclipse ADT Integration

Fri May 1 11:30:47 EDT 2015

Yes, that’s pretty much the workflow I’m implementing, with the exception
that Gradle drives everything, including CMake; not the other way around.
Gradle is, in my opinion, somewhat more general purpose than CMake, which
is laser-focused on dealing with native code, so I have structured our
multi-platform builds (Android included) in a layered approach:

1. At the lowest level, developers get the IDE projects that they’re used
to working with, so that their development workflows are largely
unaffected.
2. CMake scripts to generate the various *native-code* build systems - in
other words, I only use it for producing Visual Studio projects, Xcode
workspaces, and Makefiles that are needed to work with C/C++/Obj-C/Obj-C++
code. I still create Eclipse/IntelliJ projects by hand.
3. At the highest level, Gradle scripts to orchestrate the entire workflow

This yields a common set of high-level Gradle targets, e.g. ‘clean’,
‘build’, ‘package’, ‘test’, that any developer/continuous integration
system can execute to produce artifacts for the seven different platforms
we’re targeting.

Getting back to Android specifically - Android Studio seems to use Gradle
scripts directly, so I don’t think it's a bifurcated approach like we had
in Eclipse, where the Ant scripts were completely independent of the
Eclipse projects and had to be maintained separately. These Gradle scripts
are very flexible, so while Android Studio itself doesn’t directly support
C++ with the usual notions of debugging/IntelliSense/etc., you can still
specify your native dependencies in the Gradle scripts, and when you build
from Android Studio, it will pick them up and package them appropriately
before deployment. Here’s a related link:

http://www.shaneenishry.com/blog/2014/08/17/ndk-with-android-studio/

Once you get a good workflow with Android Studio in place, you should be
able to simply hit “Debug” from the IDE, which will build/deploy your
application and seamlessly attach its debugger to the Java side of your
code. When you hit a breakpoint on the Java side, your application will
pause and you will be able to manually attach a second debugger from
Visual Studio, to the native side of your code. This is what I did with
Eclipse, and what I still do when I debug JNI on Mac OSX, but replace
Visual Studio with Xcode. Now you can concurrently debug both sides of JNI.

Hope this helps.

Parag Chandra
Senior Software Engineer, Mobile Team
Mobile: +1.919.824.1410

 <https://ionic.com>

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309

On 5/1/15, 10:37 AM, "Robert Dailey" <rcdailey.lists at gmail.com> wrote:

>Honestly I hadn't set any expectations for the response I was going to
>get here. Your response is surprisingly hopeful IMHO.
>
>So basically the goal is to treat C++ completely separate from Java
>from a development, workflow, and build system perspective. In other
>words, if we need to debug native code, we use Visual Studio + GDB
>toolchain of sorts, all controlled and generated by CMake?
>
>And for the Java side, we switch over to Android Studio? Also
>launching on device or emulator, we initiate that from Android Studio
>as well I imagine (simply to deploy the APK to the device, not really
>for debugging). This won't be controlled by CMake at all.
>
>I guess this means the only missing piece is how the Gradle scripts
>find the *.so files from native code so it can be packaged up in the
>APK. I assume this means a post-build event on the CMake side for
>shared library targets that copies the files to
>"libs/armeabi/libfoo.so"? Or is that not the way to do it anymore with
>gradle? I have only used the ant + ndkbuild method, so I'm not sure
>how things would change. But it seems like the general direction is
>this:
>
>1. Check out source code
>2. Generate native project with CMake + android toolchain
>3. Build the native libraries with the project generated by CMake
>4. The build completes by installing all *.so files to corresponding
>paths in the source tree so Gradle/Android Studio can find them
>5. Open Android Studio & build everything
>6. Deploy to device
>
>Does this sound about right?
>
>On Thu, Apr 30, 2015 at 10:11 PM, Parag Chandra <parag at ionicsecurity.com>
>wrote:
>> Hi Robert,
>>
>> This will be a bit long-winded, so bear with me. I¹m also
>>cross-compiling
>> for Android with CMake, and am currently using Eclipse ADT for much of
>>my
>> development. I have tried hard to make Eclipse work for both the Java
>>and
>> the C++ portions of my libraries and applications, but gave up after a
>>few
>> months when it became apparent that Eclipse¹s support for Android¹s C++
>> toolchain is horribly broken. Essentially, I got it to work for brief
>> periods of time, with concurrent Java/C++ debugging, but then Eclipse
>> would inexplicably forget all of the library/include paths, display
>> thousands of red squiggles all over my code, and then refuse to launch
>>my
>> application. The only Œsolution¹ was to completely strip the project of
>> its C++ nature, add it back in, and then reconfigure all the
>> library/include paths, at which point everything would work again for a
>> few hours or a couple of days. Add to this the fact that Google has
>> officially deprecated Ant+Eclipse in favor of IntelliJ+Gradle, and it¹s
>> become clear that my time will be better spent migrating to Android
>>Studio.
>>
>> Of course, Android Studio has absolutely no support for C/C++ at the
>> moment, but at least it won¹t get in the way like Eclipse did. So I
>>think
>> a near-term solution is to use Android Studio for all of the Java code,
>>in
>> conjunction with one of several different Visual Studio-based offerings
>> for all the C++ code:
>>
>> Visual Studio 2015
>> WinGDB
>> VisualGDB
>> Android++
>>
>> Somewhere around the CMake 3.1 timeframe, they introduced a small
>>feature
>> that enables the Visual Studio generator to support any arbitrary
>> cross-toolchain, instead of just a few hardcoded ones. I¹ve been using
>> this to generate VS solutions that target Native Client as well as
>>Windows
>> Phone. Although I haven¹t yet had a chance to play around with any of
>>the
>> offerings I mentioned previously, I believe you will be able to use this
>> same feature to target Android, after you have installed one of these
>> plug-ins in Visual Studio.
>>
>> Probably not the answer you wanted to hear, but I thought I would share
>>my
>> experience and hopefully save you some trouble.
>>
>> Parag Chandra
>> Senior Software Engineer, Mobile Team
>> Mobile: +1.919.824.1410
>>
>>  <https://ionic.com>
>>
>> Ionic Security Inc.
>> 1170 Peachtree St. NE STE 400, Atlanta, GA 30309
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 4/30/15, 4:46 PM, "Robert Dailey" <rcdailey.lists at gmail.com> wrote:
>>
>>>On Wed, Mar 11, 2015 at 11:42 AM, Robert Dailey
>>><rcdailey.lists at gmail.com> wrote:
>>>> I am implementing support for Android in my CMake scripts by using
>>>> custom commands to invoke 'ant' to build the final APK. If I do it
>>>> this way, and I generate for eclipse, how can I make sure it will
>>>> integrate with the ADT plugin?
>>>>
>>>> Basically I want to be able to right-click my project in Eclipse
>>>> (generated by CMake) and "Run as Android Application" and have it
>>>> deploy to the device. What is required to make this happen?
>>>>
>>>> Also any idea how debugging will be impacted?
>>>>
>>>> Thanks.
>>>
>>>No help or advice on this?
>>>--
>>>
>>>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
>>