[Qt-creator] GSoC 2018: New feature proposal for Qt Creator

[Sree Gowtham Josyula]

Hi Orgad,

Thanks a lot for the detailed analysis and breakdown. My understanding
broadly coincides with your suggestion.
I will go ahead with your steps for implementation.

On deciding whether to use git or rsync to use for developing locally
and building remotely - I think I will design an interface which is
generic to support both git & rsync. For the current implementation, I
am slightly inclined towards rsync as it is good in terms of speed and
simplicity in implementation. I am not sure in which scenario git will
perform better than rsync. Anything scenario that comes to your mind?

Best Regards,
Sree Gowtham J

Best Regards,
Sree Gowtham Josyula
Mobile: +1 (623)-216-8029


On Wed, Mar 21, 2018 at 2:05 PM, Orgad Shaneh <orgads at gmail.com> wrote:
> On Wed, Mar 21, 2018 at 10:32 PM, Sree Gowtham Josyula
> <sreegowthamj at gmail.com> wrote:
>>
>> Hi Tobias,
>>
>> Thanks for the feedback. I have also been a little skeptical about
>> implementing the proposal in entirety in the GSoC time frame of 100
>> days. However, I have put my thoughts elaborately in the proposal to
>> convey what I had in my mind and the direction I would like to proceed
>> in.
>>
>> As you have suggested, I have cut down my initial proposal to the
>> following features -
>>
>> 1. Writing a filesystem wrapper for access of files to remote system
>> 2. Support editing of remote files and syncing them via rsync
>>
>> Future Work (Not in Scope for GSoC 2018)
>> 1. Version control support
>> 2. Support for goto-definition, code refactoring and on-fly syntax
>> checking
>> 3. Setting up of Toolchain of Remote Machine on Development Machine
>> 4. Build and Debugging of code
>>
>> Any thoughts, comments and suggestions on above proposal?
>
>
> Hi,
>
> I think you should avoid continuous work on a remote network drive. This is
> highly inefficient from our experience, at least over SMB (a linux server
> running samba, and Windows clients that access it).
>
> The way I see it, there are 2 efficient ways to work locally and build
> remotely:
> 1. rsync on build (not on every save!). From our experience, it works very
> fast - even the first sync which is full takes less than 1 minute for 18K
> files. Incremental rsync takes a few seconds.
> 2. Using Git. You can have a simple shell script that synchronizes the
> remote (assuming you don't need manual authentication for each operation on
> the remote):
> This is just a quick sketch. You need some form of initial setup, naming
> convention for directories (we duplicate the local tree structure. That is,
> if the project is in D:/Projects/SomeProject then on the remote it will
> synced to /home/user/Projects/SomeProject), error handling etc...
>
> commit=$(git stash create)
> if [ -z "$commit" ]; then commit=$(git rev-parse HEAD); fi
> git push -f build-server:project/directory $commit:refs/build
> ssh build-server 'cd project/directory && git reset --hard refs/build &&
> <build command[s]>'
>
> I sort of assume that the remote is linux. The local machine can be either
> Windows or Linux, set up with keys for SSH authentication.
>
> We do all the work locally - this means that all the Git operations are
> local and fast, and code parsing and browsing is also fast.
>
> For compilers, we have dummy (or custom) compilers. They are only used for
> correct parsing.
>
> You need the target sysroot. At least /usr/include and libraries that you
> link in your application.
>
> You can use a multiarch debugger locally. We built gdb on MinGW with
> --enable-targets=all. This covers all the possible targets.
>
> This approach narrows down your project to the following tasks (there might
> be more):
>
> Setup a working (typically SSH) connection with the remote.
> Allow the user to locate the compiler on the remote machine.
> Synchronize the sysroot on demand (let the user choose what to
> include/exclude).
> Detect compiler properties (type [GCC, Clang, ICC...], ABI, defines, include
> paths) from remote machine and pass them to the code model. Adapt include
> paths to the local sysroot.
> Configure Source Path Mapping for the debugger (you need to discover the
> user's home directory and according to the naming convention described
> above, set proper mapping. e.g. D:/Projects -> /home/user/Projects)
> Replace Build Steps with Remote Build Steps.
> Remote Build Steps will have automatic steps (like qmake step and make step
> for qmake projects) for pre-build rsync to the server (of code) and
> post-build rsync from the server (of artifacts), with options to choose
> which directories to include/exclude.
> Debugging support.
>
> Let me know if you need more information or just disagree :)
>
> Good luck!
>
> - Orgad