Important: Please read the Qt Code of Conduct -

How do I set remote path for remote deploy in Qt Creator Projects?

  • I am trying to cross compile for Raspberry Pi (a small embedded linux computer), using as a desktop computer running Slackware Linux 13.37 and Qt Creator 2.8.84/3.0.0-rc1. Everything is working up to the point of deploying to the Pi.

    Qt Creator will not let me set a value for the path for the file on the remote device, and because there is no such path set, refuses to upload.

    However, cross compiling does produce good arm binaries that do run on the Raspberry Pi if I manually sftp them over to it, and Qt Creator does happily connect to the Raspberry Pi in order to verify free disk and fetch the environment variables.

    All the details:

    Qt Creator is 2.8.84 (3.0.0-rc1) (because so far that's the only version I could find that would allow me to even start to set up a remote deploy on Slackware Linux.)

    All Plugins are version 2.8.84

    My desktop operating system: Slackware 13.37, 32 bit.

    For developing locally, everything works fine.

    However, I am trying to cross compile for (and deploy to) Rasberry Pi.

    I have cross compiler set up and that part works fine, producing binaries that do run when copied to pi.

    I have a "Device" entry set up for the Raspberry Pi. It connects with ssh key happily.

    I have a "Compiler" (named "ARM GCC") set up for the arm gcc cross compiler.

    I have a "Kit" entry set up that uses the "Raspberry Pi" device and the "ARM GCC" compiler.

    For testing this, I am creating a new "Non-Qt Project" of type "Plain C++ Project (CMake Build)", named JessesCuteApp.

    During project creation, when it prompts me to "Run CMake," I told it to use the "Unix Generator (Raspberry Pi Kit)".

    I did find that even though the "Projects" setting clearly uses the "Raspberry Pi Kit" which clearly uses the "ARM GCC" Compiler, and the ARM GCC Compiler clearly uses "compiler path"=/home/jesseg/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++ -- the build button still uses the local intel32 gcc.

    To fix the above, I had to (in Projects->Build & Run->Build) I deleted the "Make" build step and replaced it with a "Custom Process Step" to run "arm-linux-gnueabihf-g++ ../JessesCuteApp/main.cpp -o JesseCuteApp"

    So now the build button happily builds a good Raspberry Pi executable.

    (Note that I DID also try with just the default build step of "make" instead of my arm-gcc stuff - and it built using the local gcc -- but it STILL gave the error about there being no remote path set. I just wanted to make sure that the lack of a "path on target" was not being caused by make being bypassed..)

    However, during the "Run" procedures, Qt Creator fails to upload the newly created arm binary with the reason that no remote path is set for the binary. As follows:

    12:12:24: Running steps for project JessesCuteApp...
    12:12:24: Starting: "/home/jesseg/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++" ../JessesCuteApp/main.cpp -o JesseCuteApp
    12:12:24: The process "/home/jesseg/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++" exited normally.
    12:12:24: The remote file system has 4868 megabytes of free space, going ahead.
    12:12:24: Deploy step finished.
    12:12:24: Warning: No remote path set for local file '/home/jesseg/raspberrypi/JessesCuteApp-build/JessesCuteApp'. Skipping upload.
    12:12:24: All files successfully deployed.
    12:12:24: Deploy step finished.
    12:12:24: Elapsed time: 00:00.

    So then I look in Projects->Build & Run->Run, where I have it set to "Deploy to Remote Linux Host" (And is using the "Raspberry Pi Kit"), it shows, under the "Files to deploy:" header, the following:
    "Local File Path": /home/jesseg/raspberrypi/JessesCuteApp-build/JessesCuteApp
    "Remote Directory":
    (In other words, there are no files listed for the remote directory, and I cannot find ANY way to edit that or change it.)

    As you can see from the above build & run log, arm-gcc is happy, and Qt Creator is even happily connecting to the Raspberry Pi via ssh to check the free disk space. So that's all working.

    Further down on the Projects->Build & Run->Run page, under the "Run" heading, I have of course set the "Run Configuration" to "JessesCuteApp (on Remote Device)"

    And again, below that it shows the following:
    Executable on host: /home/jesseg/raspberrypi/JessesCuteApp-build/JessesCuteApp
    Executable on device: (in RED print)Remote Path Not Set

    Again, it does not allow me to set the Executable on Device. It is not even a text edit field; it is a text display only field (i.e. it is not a read-only text entry box.)

    I have tried the "Alternate executable on device:" option, but that does not cause it to attempt to upload.
    (However, it does cause it to try executing a file by the specified name on the LOCAL machine.. so I think another bug there.)

    As you can tell, I have spent all week working on this, trying different Qt Creator versions, and trying over and over again, and have only posted after trying everything I can think of!

    Any suggestions would be most gratefully received!

    Thank you very much,

    Jesse Gordon

  • See:

    on Qt Creator 2.8.1 the deploy dialog box does not have device parameters like the page indicates, but I have edited the *.pro project file and set the "target.path" parameter. This allowed me to deploy the exectuable on the target system ( wandboard in my case) using SFTP.


  • For others using CMake:
    Deploying CMake Projects to Embedded Linux Devices

    Qt Creator cannot extract files to be installed from a CMake project, and therefore, only executable targets are automatically added to deployment files. You must specify all other files in the QtCreatorDeployment.txt file that you create and place in the root directory of the CMake project.

    Use the following syntax in the file:

    Found in the "Documentation":

Log in to reply