Disable Fast deplay in CMake generated project

Hi again!
I have a problem using Fast deploy: if it is enabled after changing my project’s code the resulting .so doesnt uploaded to the device, it can be fixed by deleting resulting APK and rebuilding the solution. So I disable this feature manually, but after generating project by CMake Fast deploy becomes active again. How can I fix that?
Thanx in advance!

Hi, Paltr. Excuse if I’m missing something, but you could disable the fast deployment in a project options of a generated Visual Studio project.
According to the upload errors, please, try to upgrade to the latest release - NVIDIA Nsight Visual Studio Edition 3.2 and see if it solves the issue.
If not, please attach the log files located at %AppData%\Roaming\NVIDIA Corporation\Nsight Tegra\Logs
and describe your setup, i.e. provide the VS IDE and Windows versions along with Android SDK and NDK revisions.

Hi Paltr,

This is indeed a very annoying issue I had to workaround myself recently. At least for me, by default, NSight was not picking up changes if fast deploy was enabled either… and unfortunately, the CMake integration with NSight is rather terrible in general.

There are maybe 10 CMake target properties that you can use to configure the entire NSight project.

The workaround I initially used was was to include a .vcxproj.user file. The .vcxproj.user file allows you to override project settings. Unfortunately I do not have the source of that file to share right now (if I remember tomorrow I will post it). You can find the setting you need to add by manually disabling the Fast Deploy and selecting Save All in VS. Open the .vcxproj and search for the AntBuild section / FastDeploy.

The other thing I found out is that… For some reason, by default, the NSight plugin was searching for my .so in the ‘projectname.dir/(Configuration)' folder root. NSight, however, copies (by default) the produced shared object into the 'projectname.dir/(Configuration)/build/libs’ folder… So my solution was to have cmake, at generation time, create the ‘${CMAKE_CURRENT_BINARY_DIR}/projectname.dir/Debug’ folder (it doesn’t exist until build time normally), and create an NTFS junction point from that directory to the relative path ‘build/libs’.

On windows, its perfectly valid to create a junction to an empty directory. So, once you build the project, it will create the shared object and place it in the build/libs dir. The junction will allow the Fast Deploy to find the shared object, detect the change, and actually work.

After I figured that out, I left Fast Deploy enabled.

Also, at some point when I have some time (likely next week) I will begin updating the CMake source code to provide a non-barely-functioning integration.

@Mikhail it is of course possible to change this option manually after generation… But is a frustrating thing to do when you’re working with a team of developers, especially when its hard to notice that the deploy failed & it just runs the outdated .APK on device. Peolle have been bitten by CMake regenerating & wiping their project properties, and wondering why all of a sudden their native changes weren’t doing anything… This is mainly an issue with the CMake integration to the plugin

Hi all! Thanks a lot for your responces.

It’s very interesting comment, could you explain how did you found this? I tried your solution - made junction point ‘projectname.dir/$(Configuration)’ to the folder containing my so, but this didn’t solve the problem. So maybe NSight looks my so in some other place in my case? I would like to discover it :)

Hi, morbik.

Could you please provide some suggestions how the CMake project generation could be improved?

Actually, that folder contains the not stripped dynamic libraries, so the plugin reads them to load the symbols in the debugger.

Could you please contact me first before starting the work? As a product maintainer, I’ll wish to ensure some knowledge transfer on CMake generator support.

Hi Paltr,

That’s a shame that didn’t work for you. Just to make sure, you can’t junction directly to the folder with the SO, you have to junction to the folder containing the architecture specific subfolder (for me I’m targeting armeabi-v7a).

Oh this thought just occurred to me. I only tested the fast deploy junction trick with tegra 3.2. Are you using the latest version / can you upgrade?