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

[Sree Gowtham Josyula]

 sdb in
>> >> future
>> >> 2. Interface for setting up a toolkit (Compiler, Debugger, Qt
>> >> Tool-chain, cmake, qmake, qbs, sysroot) of a Remote Machine on the
>> >> Development Machine's IDE
>> >> 3. Opening projects of Remote Machine in Development Machine (using an
>> >> interface identical to the one used for opening project on Development
>> >> Machine)
>> >> 4. Automatic syncing of workspace between Development Machine and
>> >> Remote Machine(on every save & periodically) - to be implemented using
>> >> rsync
>> >> 5. Compilation of code on the remote machine with the tool-chain setup
>> >> there
>> >> 6. Execution & Debugging code on Remote Machine or Target Machine
>> >> 7. Supporting Clang based code completion, goto-definition &
>> >> refactoring. Clang will run on the development machine
>> >> 8. Provide Version Control interface for the project in Development
>> >> Machine and perform corresponding actions on Remote Machine
>> >> 9. Support multiple platforms(Windows, Mac, GNU/Linux) for the
>> >> Development Machine and Remote Machine environment
>> >>
>> >> Plausible Difficulties
>> >> 1. Writing a filesystem wrapper for handling access of files on remote
>> >> system -  This change could impact multiple other plugins and it needs
>> >> to be thoroughly tested for multiple use-cases
>> >>
>> >> Mentor -
>> >> To be decided
>> >>
>> >> Kindly share your thoughts, comments and suggestions on the same.
>> >>
>> >> With Best Regards,
>> >> Sree Gowtham Josyula
>> >>
>> >> On Tue, Mar 13, 2018 at 2:20 AM, Riitta-Leena Miettinen
>> >>  wrote:
>> >>> Hello,
>> >>>
>> >>> Creating custom compilers is documented here:
>> >>> http://doc.qt.io/qtcreator/creator-tool-chains.html#adding-custom-compilers
>> >>>
>> >>> Leena
>> >>>
>> >>>
>> >>> --
>> >>> Leena Miettinen
>> >>> Documentation Engineer
>> >>>
>> >>> The Qt Company Germany GmbH
>> >>> Rudower Chaussee 13
>> >>> D-12489, Berlin, Germany
>> >>> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
>> >>> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
>> >>> Charlottenburg, HRB 144331 B
>> >>> riitta-leena.mietti...@qt.io
>> >>> +49 30 63 92 3255
>> >>> http://qt.io
>> >>>
>> >>>> -Original Message-
>> >>>> From: Qt-creator
>> >>>> [mailto:qt-creator-bounces+riitta-leena.miettinen=qt.io@qt-
>> >>>> project.org] On Behalf Of Eike Ziller
>> >>>> Sent: Dienstag, 13. März 2018 10:00
>> >>>> To: Sree Gowtham Josyula 
>> >>>> Cc: qt-creator@qt-project.org
>> >>>> Subject: Re: [Qt-creator] GSoC 2018: New feature proposal for Qt
>> >>>> Creator
>> >>>>
>> >>>>
>> >>>> > On Mar 13, 2018, at 09:54, Sree Gowtham Josyula
>> >>>>  wrote:
>> >>>> >
>> >>>> > Hi Orgad,
>> >>>> >
>> >>>> > I do not understand what you mean by a custom compiler. Is it some
>> >>>> > sort of a script on development machine which returns the same
>> >>>> > values
>> >>>> > as the remote compiler when queried with -v and -dM flags? What is
>> >>>> > its
>> >>>> > significance?
>> >>>>
>> >>>> In Qt Creator settings (Build & Run > Compilers > Add > Custom) you
>> >>>> can create
>> >>>> a “custom” compiler, manually specifying ABI, predefined macros,
>> >>>> system
>> >>>> include paths etc.
>> >>>> Then you can set that as a compiler for the kit, to make code
>> >>>> completion work
>> >>>> with these values.
>> >>>>
>> >>>> Br, Eike
>> >>>>
>> >>>> >
>> >>>> > On Tue, Mar 13, 2018 at 12:41 AM, Orgad Shane

Re: [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  wrote:
> On Wed, Mar 21, 2018 at 10:32 PM, Sree Gowtham Josyula
>  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 &&
> '
>
> 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
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

[Ariel Molina]

> >> 7. Supporting Clang based code completion, goto-definition &
> >> refactoring. Clang will run on the development machine
> >> 8. Provide Version Control interface for the project in Development
> >> Machine and perform corresponding actions on Remote Machine
> >> 9. Support multiple platforms(Windows, Mac, GNU/Linux) for the
> >> Development Machine and Remote Machine environment
> >>
> >> Plausible Difficulties
> >> 1. Writing a filesystem wrapper for handling access of files on remote
> >> system -  This change could impact multiple other plugins and it needs
> >> to be thoroughly tested for multiple use-cases
> >>
> >> Mentor -
> >> To be decided
> >>
> >> Kindly share your thoughts, comments and suggestions on the same.
> >>
> >> With Best Regards,
> >> Sree Gowtham Josyula
> >>
> >> On Tue, Mar 13, 2018 at 2:20 AM, Riitta-Leena Miettinen
> >>  wrote:
> >>> Hello,
> >>>
> >>> Creating custom compilers is documented here:
> http://doc.qt.io/qtcreator/creator-tool-chains.html#
> adding-custom-compilers
> >>>
> >>> Leena
> >>>
> >>> 
> --
> >>> Leena Miettinen
> >>> Documentation Engineer
> >>>
> >>> The Qt Company Germany GmbH
> >>> Rudower Chaussee 13
> >>> D-12489, Berlin, Germany
> >>> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
> >>> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> >>> riitta-leena.mietti...@qt.io
> >>> +49 30 63 92 3255
> >>> http://qt.io
> >>>
> >>>> -Original Message-
> >>>> From: Qt-creator [mailto:qt-creator-bounces+riitta-leena.miettinen
> =qt.io@qt-
> >>>> project.org] On Behalf Of Eike Ziller
> >>>> Sent: Dienstag, 13. März 2018 10:00
> >>>> To: Sree Gowtham Josyula 
> >>>> Cc: qt-creator@qt-project.org
> >>>> Subject: Re: [Qt-creator] GSoC 2018: New feature proposal for Qt
> Creator
> >>>>
> >>>>
> >>>> > On Mar 13, 2018, at 09:54, Sree Gowtham Josyula
> >>>>  wrote:
> >>>> >
> >>>> > Hi Orgad,
> >>>> >
> >>>> > I do not understand what you mean by a custom compiler. Is it some
> >>>> > sort of a script on development machine which returns the same
> values
> >>>> > as the remote compiler when queried with -v and -dM flags? What is
> its
> >>>> > significance?
> >>>>
> >>>> In Qt Creator settings (Build & Run > Compilers > Add > Custom) you
> can create
> >>>> a “custom” compiler, manually specifying ABI, predefined macros,
> system
> >>>> include paths etc.
> >>>> Then you can set that as a compiler for the kit, to make code
> completion work
> >>>> with these values.
> >>>>
> >>>> Br, Eike
> >>>>
> >>>> >
> >>>> > On Tue, Mar 13, 2018 at 12:41 AM, Orgad Shaneh 
> >>>> wrote:
> >>>> >> On Mon, Mar 12, 2018 at 11:33 PM, Harri Pasanen 
> >>>> wrote:
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>>> On Mar 12, 2018, at 4:32 PM, Konstantin Tokarev <
> annu...@yandex.ru>
> >>>> >>>> wrote:
> >>>> >>>>
> >>>> >>>>
> >>>> >>>>
> >>>> >>>> 12.03.2018, 15:46, "Orgad Shaneh" :
> >>>> >>>>> On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula
> >>>> >>>>>  wrote:
> >>>> >>>>>> Hi André & Everyone,
> >>>> >>>>>>
> >>>> >>>>>> Thanks for showing interest in my suggestion.
> QTCREATORBUG-16246
> >>>> is
> >>>> >>>>>> indeed almost like what I had intended in my previous mail.
> >>>> >>>>>>
> >>>> >>>>>>> * Would it be enough to have the files on a network share
> instead of
> >>>> >>>>&g

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

[Orgad Shaneh]

On Wed, Mar 21, 2018 at 10:32 PM, Sree Gowtham Josyula <
sreegowth...@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 &&
'

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):

   1. Setup a working (typically SSH) connection with the remote.
   2. Allow the user to locate the compiler on the remote machine.
   3. Synchronize the sysroot on demand (let the user choose what to
   include/exclude).
   4. 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.
   5. 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)
   6. Replace Build Steps with Remote Build Steps.
   7. 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.
   8. Debugging support.

Let me know if you need more information or just disagree :)

Good luck!

- Orgad
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

[Sree Gowtham Josyula]

3, 2018 at 2:20 AM, Riitta-Leena Miettinen
>>  wrote:
>>> Hello,
>>>
>>> Creating custom compilers is documented here: 
>>> http://doc.qt.io/qtcreator/creator-tool-chains.html#adding-custom-compilers
>>>
>>> Leena
>>>
>>> --
>>> Leena Miettinen
>>> Documentation Engineer
>>>
>>> The Qt Company Germany GmbH
>>> Rudower Chaussee 13
>>> D-12489, Berlin, Germany
>>> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
>>> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
>>> HRB 144331 B
>>> riitta-leena.mietti...@qt.io
>>> +49 30 63 92 3255
>>> http://qt.io
>>>
>>>> -Original Message-
>>>> From: Qt-creator 
>>>> [mailto:qt-creator-bounces+riitta-leena.miettinen=qt.io@qt-
>>>> project.org] On Behalf Of Eike Ziller
>>>> Sent: Dienstag, 13. März 2018 10:00
>>>> To: Sree Gowtham Josyula 
>>>> Cc: qt-creator@qt-project.org
>>>> Subject: Re: [Qt-creator] GSoC 2018: New feature proposal for Qt Creator
>>>>
>>>>
>>>> > On Mar 13, 2018, at 09:54, Sree Gowtham Josyula
>>>>  wrote:
>>>> >
>>>> > Hi Orgad,
>>>> >
>>>> > I do not understand what you mean by a custom compiler. Is it some
>>>> > sort of a script on development machine which returns the same values
>>>> > as the remote compiler when queried with -v and -dM flags? What is its
>>>> > significance?
>>>>
>>>> In Qt Creator settings (Build & Run > Compilers > Add > Custom) you can 
>>>> create
>>>> a “custom” compiler, manually specifying ABI, predefined macros, system
>>>> include paths etc.
>>>> Then you can set that as a compiler for the kit, to make code completion 
>>>> work
>>>> with these values.
>>>>
>>>> Br, Eike
>>>>
>>>> >
>>>> > On Tue, Mar 13, 2018 at 12:41 AM, Orgad Shaneh 
>>>> wrote:
>>>> >> On Mon, Mar 12, 2018 at 11:33 PM, Harri Pasanen 
>>>> wrote:
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>> On Mar 12, 2018, at 4:32 PM, Konstantin Tokarev 
>>>> >>>> wrote:
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> 12.03.2018, 15:46, "Orgad Shaneh" :
>>>> >>>>> On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula
>>>> >>>>>  wrote:
>>>> >>>>>> Hi André & Everyone,
>>>> >>>>>>
>>>> >>>>>> Thanks for showing interest in my suggestion. QTCREATORBUG-16246
>>>> is
>>>> >>>>>> indeed almost like what I had intended in my previous mail.
>>>> >>>>>>
>>>> >>>>>>> * Would it be enough to have the files on a network share instead 
>>>> >>>>>>> of
>>>> >>>>>>> rsync'ing them?
>>>> >>>>>>> * Is it really needed to have Clang running on the remote machine?
>>>> >>>>>>> Would it be enough to have access to the included headers on
>>>> remote?
>>>> >>>>>>
>>>> >>>>>> I think Network share you suggest is a good idea. It solves both of
>>>> >>>>>> the above issues. With network sharing, we wouldn't need rsync and 
>>>> >>>>>> we
>>>> >>>>>> wouldn't need to run clang on remote machine.
>>>> >>>>>>
>>>> >>>>>> I will refine my initial proposal and put forth a more detailed
>>>> >>>>>> proposal considering your suggestions and more use-cases asap.
>>>> >>>>>> If you have any other thoughts and suggestions, kindly let me know.
>>>> >>>>>
>>>> >>>>> Hi,
>>>> >>>>>
>>>> >>>>> I strongly suggest not to use network share. We tried that several
>>>> >>>>> years ago (with SMB), 

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

[Tobias Hunger]

Hi Sree!

I think you are seriously underestimating the task at hand. I do not
see how you will do all this in the timeframe set by google for GSoC.

One step in the direction you are aiming at is to implement a
filesystem wrapper and introduce that into creator. That is a gigantic
task in itself.

Best Regards,
Tobias

On Wed, Mar 21, 2018 at 10:59 AM, Sree Gowtham Josyula
 wrote:
> Hello Everyone,
>
> Thanks for your interest and suggestions in my proposal. With your
> suggestions, I have modified my initial idea. Please find the modified
> idea in the link below.
> Link - 
> https://docs.google.com/document/d/1hC2rTrDN5UvgpS57S5ixLiuJUSdR0KPRfNE9wPm1hc8/edit?usp=sharing
> I am posting content of the above link below for your convenience -
>
> Title - Remote System Development Plugin for Qt Creator
>
> Keywords
> 1. Development Machine - This is the machine where the user interacts
> directly with Qt Creator IDE for development tasks (editing,
> compilation and debugging). The development tasks are triggered
> directly by user using the IDE interface on this machine.
> 2. Remote Machine - This is the machine to which the development tasks
> are routed by the Qt Creator IDE of Development Machine to perform the
> development tasks and results of which are returned to the user to be
> displayed on the Development Machine.
>
> Summary
> In order to enable development of a Qt and C++ projects on a remote
> machine, this Qt Creator IDE plugin enables editing, compiling and
> debugging of a project on a remote machine via the development
> machine, supporting existing Qt Creator IDE features like version
> control, code-completion, syntax-highlighting, goto-definition,
> code-refactoring and syntax-parsing.
> Link to discussion on Qt Creator mailing list -
> http://lists.qt-project.org/pipermail/qt-creator/2018-March/007159.html
>
> Features
> 1. IDE Interface for public key registration of development machine on
> Remote Machine for seamless syncing of files between the two machines
> via ssh. Also, making an extensible interface to support adb, sdb in
> future
> 2. Interface for setting up a toolkit (Compiler, Debugger, Qt
> Tool-chain, cmake, qmake, qbs, sysroot) of a Remote Machine on the
> Development Machine's IDE
> 3. Opening projects of Remote Machine in Development Machine (using an
> interface identical to the one used for opening project on Development
> Machine)
> 4. Automatic syncing of workspace between Development Machine and
> Remote Machine(on every save & periodically) - to be implemented using
> rsync
> 5. Compilation of code on the remote machine with the tool-chain setup there
> 6. Execution & Debugging code on Remote Machine or Target Machine
> 7. Supporting Clang based code completion, goto-definition &
> refactoring. Clang will run on the development machine
> 8. Provide Version Control interface for the project in Development
> Machine and perform corresponding actions on Remote Machine
> 9. Support multiple platforms(Windows, Mac, GNU/Linux) for the
> Development Machine and Remote Machine environment
>
> Plausible Difficulties
> 1. Writing a filesystem wrapper for handling access of files on remote
> system -  This change could impact multiple other plugins and it needs
> to be thoroughly tested for multiple use-cases
>
> Mentor -
> To be decided
>
> Kindly share your thoughts, comments and suggestions on the same.
>
> With Best Regards,
> Sree Gowtham Josyula
>
> On Tue, Mar 13, 2018 at 2:20 AM, Riitta-Leena Miettinen
>  wrote:
>> Hello,
>>
>> Creating custom compilers is documented here: 
>> http://doc.qt.io/qtcreator/creator-tool-chains.html#adding-custom-compilers
>>
>> Leena
>>
>> --
>> Leena Miettinen
>> Documentation Engineer
>>
>> The Qt Company Germany GmbH
>> Rudower Chaussee 13
>> D-12489, Berlin, Germany
>> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
>> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
>> HRB 144331 B
>> riitta-leena.mietti...@qt.io
>> +49 30 63 92 3255
>> http://qt.io
>>
>>> -Original Message-
>>> From: Qt-creator [mailto:qt-creator-bounces+riitta-leena.miettinen=qt.io@qt-
>>> project.org] On Behalf Of Eike Ziller
>>> Sent: Dienstag, 13. März 2018 10:00
>>> To: Sree Gowtham Josyula 
>>> Cc: qt-creator@qt-project.org
>>> Subject: Re: [Qt-creator] GSoC 2018: New feature proposal for Qt Creator
>>>
>>>
>>> > On Mar 13, 2018, at 09:54, Sree Gowtham Josyula
&g

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

[Sree Gowtham Josyula]

Hello Everyone,

Thanks for your interest and suggestions in my proposal. With your
suggestions, I have modified my initial idea. Please find the modified
idea in the link below.
Link - 
https://docs.google.com/document/d/1hC2rTrDN5UvgpS57S5ixLiuJUSdR0KPRfNE9wPm1hc8/edit?usp=sharing
I am posting content of the above link below for your convenience -

Title - Remote System Development Plugin for Qt Creator

Keywords
1. Development Machine - This is the machine where the user interacts
directly with Qt Creator IDE for development tasks (editing,
compilation and debugging). The development tasks are triggered
directly by user using the IDE interface on this machine.
2. Remote Machine - This is the machine to which the development tasks
are routed by the Qt Creator IDE of Development Machine to perform the
development tasks and results of which are returned to the user to be
displayed on the Development Machine.

Summary
In order to enable development of a Qt and C++ projects on a remote
machine, this Qt Creator IDE plugin enables editing, compiling and
debugging of a project on a remote machine via the development
machine, supporting existing Qt Creator IDE features like version
control, code-completion, syntax-highlighting, goto-definition,
code-refactoring and syntax-parsing.
Link to discussion on Qt Creator mailing list -
http://lists.qt-project.org/pipermail/qt-creator/2018-March/007159.html

Features
1. IDE Interface for public key registration of development machine on
Remote Machine for seamless syncing of files between the two machines
via ssh. Also, making an extensible interface to support adb, sdb in
future
2. Interface for setting up a toolkit (Compiler, Debugger, Qt
Tool-chain, cmake, qmake, qbs, sysroot) of a Remote Machine on the
Development Machine's IDE
3. Opening projects of Remote Machine in Development Machine (using an
interface identical to the one used for opening project on Development
Machine)
4. Automatic syncing of workspace between Development Machine and
Remote Machine(on every save & periodically) - to be implemented using
rsync
5. Compilation of code on the remote machine with the tool-chain setup there
6. Execution & Debugging code on Remote Machine or Target Machine
7. Supporting Clang based code completion, goto-definition &
refactoring. Clang will run on the development machine
8. Provide Version Control interface for the project in Development
Machine and perform corresponding actions on Remote Machine
9. Support multiple platforms(Windows, Mac, GNU/Linux) for the
Development Machine and Remote Machine environment

Plausible Difficulties
1. Writing a filesystem wrapper for handling access of files on remote
system -  This change could impact multiple other plugins and it needs
to be thoroughly tested for multiple use-cases

Mentor -
To be decided

Kindly share your thoughts, comments and suggestions on the same.

With Best Regards,
Sree Gowtham Josyula

On Tue, Mar 13, 2018 at 2:20 AM, Riitta-Leena Miettinen
 wrote:
> Hello,
>
> Creating custom compilers is documented here: 
> http://doc.qt.io/qtcreator/creator-tool-chains.html#adding-custom-compilers
>
> Leena
>
> --
> Leena Miettinen
> Documentation Engineer
>
> The Qt Company Germany GmbH
> Rudower Chaussee 13
> D-12489, Berlin, Germany
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
> HRB 144331 B
> riitta-leena.mietti...@qt.io
> +49 30 63 92 3255
> http://qt.io
>
>> -Original Message-
>> From: Qt-creator [mailto:qt-creator-bounces+riitta-leena.miettinen=qt.io@qt-
>> project.org] On Behalf Of Eike Ziller
>> Sent: Dienstag, 13. März 2018 10:00
>> To: Sree Gowtham Josyula 
>> Cc: qt-creator@qt-project.org
>> Subject: Re: [Qt-creator] GSoC 2018: New feature proposal for Qt Creator
>>
>>
>> > On Mar 13, 2018, at 09:54, Sree Gowtham Josyula
>>  wrote:
>> >
>> > Hi Orgad,
>> >
>> > I do not understand what you mean by a custom compiler. Is it some
>> > sort of a script on development machine which returns the same values
>> > as the remote compiler when queried with -v and -dM flags? What is its
>> > significance?
>>
>> In Qt Creator settings (Build & Run > Compilers > Add > Custom) you can 
>> create
>> a “custom” compiler, manually specifying ABI, predefined macros, system
>> include paths etc.
>> Then you can set that as a compiler for the kit, to make code completion work
>> with these values.
>>
>> Br, Eike
>>
>> >
>> > On Tue, Mar 13, 2018 at 12:41 AM, Orgad Shaneh 
>> wrote:
>> >> On Mon, 

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

[Riitta-Leena Miettinen]

Hello,

Creating custom compilers is documented here: 
http://doc.qt.io/qtcreator/creator-tool-chains.html#adding-custom-compilers

Leena

--
Leena Miettinen
Documentation Engineer

The Qt Company Germany GmbH
Rudower Chaussee 13
D-12489, Berlin, Germany
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho 
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B
riitta-leena.mietti...@qt.io
+49 30 63 92 3255
http://qt.io 

> -Original Message-
> From: Qt-creator [mailto:qt-creator-bounces+riitta-leena.miettinen=qt.io@qt-
> project.org] On Behalf Of Eike Ziller
> Sent: Dienstag, 13. März 2018 10:00
> To: Sree Gowtham Josyula 
> Cc: qt-creator@qt-project.org
> Subject: Re: [Qt-creator] GSoC 2018: New feature proposal for Qt Creator
> 
> 
> > On Mar 13, 2018, at 09:54, Sree Gowtham Josyula
>  wrote:
> >
> > Hi Orgad,
> >
> > I do not understand what you mean by a custom compiler. Is it some
> > sort of a script on development machine which returns the same values
> > as the remote compiler when queried with -v and -dM flags? What is its
> > significance?
> 
> In Qt Creator settings (Build & Run > Compilers > Add > Custom) you can create
> a “custom” compiler, manually specifying ABI, predefined macros, system
> include paths etc.
> Then you can set that as a compiler for the kit, to make code completion work
> with these values.
> 
> Br, Eike
> 
> >
> > On Tue, Mar 13, 2018 at 12:41 AM, Orgad Shaneh 
> wrote:
> >> On Mon, Mar 12, 2018 at 11:33 PM, Harri Pasanen 
> wrote:
> >>>
> >>>
> >>>
> >>>> On Mar 12, 2018, at 4:32 PM, Konstantin Tokarev 
> >>>> wrote:
> >>>>
> >>>>
> >>>>
> >>>> 12.03.2018, 15:46, "Orgad Shaneh" :
> >>>>> On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula
> >>>>>  wrote:
> >>>>>> Hi André & Everyone,
> >>>>>>
> >>>>>> Thanks for showing interest in my suggestion. QTCREATORBUG-16246
> is
> >>>>>> indeed almost like what I had intended in my previous mail.
> >>>>>>
> >>>>>>> * Would it be enough to have the files on a network share instead of
> >>>>>>> rsync'ing them?
> >>>>>>> * Is it really needed to have Clang running on the remote machine?
> >>>>>>> Would it be enough to have access to the included headers on
> remote?
> >>>>>>
> >>>>>> I think Network share you suggest is a good idea. It solves both of
> >>>>>> the above issues. With network sharing, we wouldn't need rsync and we
> >>>>>> wouldn't need to run clang on remote machine.
> >>>>>>
> >>>>>> I will refine my initial proposal and put forth a more detailed
> >>>>>> proposal considering your suggestions and more use-cases asap.
> >>>>>> If you have any other thoughts and suggestions, kindly let me know.
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I strongly suggest not to use network share. We tried that several
> >>>>> years ago (with SMB), and it was awful. Parsing takes forever over the
> >>>>> network. Working locally and using rsync before build works much better
> >>>>> (once you have ssh keys set up).
> >>>>>
> >>>>> We have a local partial copy of the sysroot, which includes the include
> >>>>> directory, and the shared libraries that are linked with our application
> >>>>> (for each platform we support).
> >>>>
> >>>> Why not to go further and get full copy and toolchain locally?
> >>>>
> >>>
> >>> Network share would in a proper setup be the local disk of the compilation
> >>> server.
> >>>
> >>> Also, one cannot copy locally the toolchain if the server is different OS,
> >>> unless a cross compilation environment is setup, which in itself is a 
> >>> major
> >>> piece of work.
> >>
> >>
> >> That's right. What we did was to create dummy compilers that return the
> same
> >> values as the real compiler when called with -v and -dM etc. This is no
> >> longer needed, as a "custom compiler" can be created instead.
> >>
> >> I suggest to read the values from the remote compiler, and create a local
> >> custom compiler with the same values (except include directories which
> >> should be adapted to the local sysroot location).
> >>
> >> - Orgad
> > ___
> > Qt-creator mailing list
> > Qt-creator@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/qt-creator
> 
> --
> Eike Ziller
> Principal Software Engineer
> 
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
> eike.zil...@qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
> HRB
> 144331 B
> 
> ___
> Qt-creator mailing list
> Qt-creator@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

[Eike Ziller]

> On Mar 13, 2018, at 09:54, Sree Gowtham Josyula  
> wrote:
> 
> Hi Orgad,
> 
> I do not understand what you mean by a custom compiler. Is it some
> sort of a script on development machine which returns the same values
> as the remote compiler when queried with -v and -dM flags? What is its
> significance?

In Qt Creator settings (Build & Run > Compilers > Add > Custom) you can create 
a “custom” compiler, manually specifying ABI, predefined macros, system include 
paths etc.
Then you can set that as a compiler for the kit, to make code completion work 
with these values.

Br, Eike

> 
> On Tue, Mar 13, 2018 at 12:41 AM, Orgad Shaneh  wrote:
>> On Mon, Mar 12, 2018 at 11:33 PM, Harri Pasanen  wrote:
>>> 
>>> 
>>> 
 On Mar 12, 2018, at 4:32 PM, Konstantin Tokarev 
 wrote:
 
 
 
 12.03.2018, 15:46, "Orgad Shaneh" :
> On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula
>  wrote:
>> Hi André & Everyone,
>> 
>> Thanks for showing interest in my suggestion. QTCREATORBUG-16246 is
>> indeed almost like what I had intended in my previous mail.
>> 
>>> * Would it be enough to have the files on a network share instead of
>>> rsync'ing them?
>>> * Is it really needed to have Clang running on the remote machine?
>>> Would it be enough to have access to the included headers on remote?
>> 
>> I think Network share you suggest is a good idea. It solves both of
>> the above issues. With network sharing, we wouldn't need rsync and we
>> wouldn't need to run clang on remote machine.
>> 
>> I will refine my initial proposal and put forth a more detailed
>> proposal considering your suggestions and more use-cases asap.
>> If you have any other thoughts and suggestions, kindly let me know.
> 
> Hi,
> 
> I strongly suggest not to use network share. We tried that several
> years ago (with SMB), and it was awful. Parsing takes forever over the
> network. Working locally and using rsync before build works much better
> (once you have ssh keys set up).
> 
> We have a local partial copy of the sysroot, which includes the include
> directory, and the shared libraries that are linked with our application
> (for each platform we support).
 
 Why not to go further and get full copy and toolchain locally?
 
>>> 
>>> Network share would in a proper setup be the local disk of the compilation
>>> server.
>>> 
>>> Also, one cannot copy locally the toolchain if the server is different OS,
>>> unless a cross compilation environment is setup, which in itself is a major
>>> piece of work.
>> 
>> 
>> That's right. What we did was to create dummy compilers that return the same
>> values as the real compiler when called with -v and -dM etc. This is no
>> longer needed, as a "custom compiler" can be created instead.
>> 
>> I suggest to read the values from the remote compiler, and create a local
>> custom compiler with the same values (except include directories which
>> should be adapted to the local sysroot location).
>> 
>> - Orgad
> ___
> Qt-creator mailing list
> Qt-creator@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

[Sree Gowtham Josyula]

Hi Orgad,

I do not understand what you mean by a custom compiler. Is it some
sort of a script on development machine which returns the same values
as the remote compiler when queried with -v and -dM flags? What is its
significance?

Best Regards,
Sree Gowtham Josyula


On Tue, Mar 13, 2018 at 12:41 AM, Orgad Shaneh  wrote:
> On Mon, Mar 12, 2018 at 11:33 PM, Harri Pasanen  wrote:
>>
>>
>>
>> > On Mar 12, 2018, at 4:32 PM, Konstantin Tokarev 
>> > wrote:
>> >
>> >
>> >
>> > 12.03.2018, 15:46, "Orgad Shaneh" :
>> >> On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula
>> >>  wrote:
>> >>> Hi André & Everyone,
>> >>>
>> >>> Thanks for showing interest in my suggestion. QTCREATORBUG-16246 is
>> >>> indeed almost like what I had intended in my previous mail.
>> >>>
>>  * Would it be enough to have the files on a network share instead of
>>  rsync'ing them?
>>  * Is it really needed to have Clang running on the remote machine?
>>  Would it be enough to have access to the included headers on remote?
>> >>>
>> >>> I think Network share you suggest is a good idea. It solves both of
>> >>> the above issues. With network sharing, we wouldn't need rsync and we
>> >>> wouldn't need to run clang on remote machine.
>> >>>
>> >>> I will refine my initial proposal and put forth a more detailed
>> >>> proposal considering your suggestions and more use-cases asap.
>> >>> If you have any other thoughts and suggestions, kindly let me know.
>> >>
>> >> Hi,
>> >>
>> >> I strongly suggest not to use network share. We tried that several
>> >> years ago (with SMB), and it was awful. Parsing takes forever over the
>> >> network. Working locally and using rsync before build works much better
>> >> (once you have ssh keys set up).
>> >>
>> >> We have a local partial copy of the sysroot, which includes the include
>> >> directory, and the shared libraries that are linked with our application
>> >> (for each platform we support).
>> >
>> > Why not to go further and get full copy and toolchain locally?
>> >
>>
>> Network share would in a proper setup be the local disk of the compilation
>> server.
>>
>> Also, one cannot copy locally the toolchain if the server is different OS,
>> unless a cross compilation environment is setup, which in itself is a major
>> piece of work.
>
>
> That's right. What we did was to create dummy compilers that return the same
> values as the real compiler when called with -v and -dM etc. This is no
> longer needed, as a "custom compiler" can be created instead.
>
> I suggest to read the values from the remote compiler, and create a local
> custom compiler with the same values (except include directories which
> should be adapted to the local sysroot location).
>
> - Orgad
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

[Orgad Shaneh]

On Mon, Mar 12, 2018 at 11:33 PM, Harri Pasanen  wrote:

>
>
> > On Mar 12, 2018, at 4:32 PM, Konstantin Tokarev 
> wrote:
> >
> >
> >
> > 12.03.2018, 15:46, "Orgad Shaneh" :
> >> On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula <
> sreegowth...@gmail.com> wrote:
> >>> Hi André & Everyone,
> >>>
> >>> Thanks for showing interest in my suggestion. QTCREATORBUG-16246 is
> >>> indeed almost like what I had intended in my previous mail.
> >>>
>  * Would it be enough to have the files on a network share instead of
> rsync'ing them?
>  * Is it really needed to have Clang running on the remote machine?
> Would it be enough to have access to the included headers on remote?
> >>>
> >>> I think Network share you suggest is a good idea. It solves both of
> >>> the above issues. With network sharing, we wouldn't need rsync and we
> >>> wouldn't need to run clang on remote machine.
> >>>
> >>> I will refine my initial proposal and put forth a more detailed
> >>> proposal considering your suggestions and more use-cases asap.
> >>> If you have any other thoughts and suggestions, kindly let me know.
> >>
> >> Hi,
> >>
> >> I strongly suggest not to use network share. We tried that several
> years ago (with SMB), and it was awful. Parsing takes forever over the
> network. Working locally and using rsync before build works much better
> (once you have ssh keys set up).
> >>
> >> We have a local partial copy of the sysroot, which includes the include
> directory, and the shared libraries that are linked with our application
> (for each platform we support).
> >
> > Why not to go further and get full copy and toolchain locally?
> >
>
> Network share would in a proper setup be the local disk of the compilation
> server.
>
> Also, one cannot copy locally the toolchain if the server is different OS,
> unless a cross compilation environment is setup, which in itself is a major
> piece of work.
>

That's right. What we did was to create dummy compilers that return the
same values as the real compiler when called with -v and -dM etc. This is
no longer needed, as a "custom compiler" can be created instead.

I suggest to read the values from the remote compiler, and create a local
custom compiler with the same values (except include directories which
should be adapted to the local sysroot location).

- Orgad
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

[Harri Pasanen]

> On Mar 12, 2018, at 4:32 PM, Konstantin Tokarev  wrote:
> 
> 
> 
> 12.03.2018, 15:46, "Orgad Shaneh" :
>> On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula 
>>  wrote:
>>> Hi André & Everyone,
>>> 
>>> Thanks for showing interest in my suggestion. QTCREATORBUG-16246 is
>>> indeed almost like what I had intended in my previous mail.
>>> 
 * Would it be enough to have the files on a network share instead of 
 rsync'ing them?
 * Is it really needed to have Clang running on the remote machine? Would 
 it be enough to have access to the included headers on remote?
>>> 
>>> I think Network share you suggest is a good idea. It solves both of
>>> the above issues. With network sharing, we wouldn't need rsync and we
>>> wouldn't need to run clang on remote machine.
>>> 
>>> I will refine my initial proposal and put forth a more detailed
>>> proposal considering your suggestions and more use-cases asap.
>>> If you have any other thoughts and suggestions, kindly let me know.
>> 
>> Hi,
>> 
>> I strongly suggest not to use network share. We tried that several years ago 
>> (with SMB), and it was awful. Parsing takes forever over the network. 
>> Working locally and using rsync before build works much better (once you 
>> have ssh keys set up).
>> 
>> We have a local partial copy of the sysroot, which includes the include 
>> directory, and the shared libraries that are linked with our application 
>> (for each platform we support).
> 
> Why not to go further and get full copy and toolchain locally?
> 

Network share would in a proper setup be the local disk of the compilation 
server.   

Also, one cannot copy locally the toolchain if the server is different OS, 
unless a cross compilation environment is setup, which in itself is a major 
piece of work.

I’d prefer rsync though, as it would be easier to setup the ports/ firewalls 
etc., plus it would be faster than the network share.   In my hypothetical 
use-case the compilation server is often in a different country, and VPN would 
be the only feasible network share setup.

Just my 2 cents,
Harri

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

[Konstantin Tokarev]

12.03.2018, 15:46, "Orgad Shaneh" :
> On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula 
>  wrote:
>> Hi André & Everyone,
>>
>> Thanks for showing interest in my suggestion. QTCREATORBUG-16246 is
>> indeed almost like what I had intended in my previous mail.
>>
>>> * Would it be enough to have the files on a network share instead of 
>>> rsync'ing them?
>>> * Is it really needed to have Clang running on the remote machine? Would it 
>>> be enough to have access to the included headers on remote?
>>
>> I think Network share you suggest is a good idea. It solves both of
>> the above issues. With network sharing, we wouldn't need rsync and we
>> wouldn't need to run clang on remote machine.
>>
>> I will refine my initial proposal and put forth a more detailed
>> proposal considering your suggestions and more use-cases asap.
>> If you have any other thoughts and suggestions, kindly let me know.
>
> Hi,
>
> I strongly suggest not to use network share. We tried that several years ago 
> (with SMB), and it was awful. Parsing takes forever over the network. Working 
> locally and using rsync before build works much better (once you have ssh 
> keys set up).
>
> We have a local partial copy of the sysroot, which includes the include 
> directory, and the shared libraries that are linked with our application (for 
> each platform we support).

Why not to go further and get full copy and toolchain locally?


-- 
Regards,
Konstantin
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

[Orgad Shaneh]

On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula <
sreegowth...@gmail.com> wrote:

> Hi André & Everyone,
>
> Thanks for showing interest in my suggestion. QTCREATORBUG-16246 is
> indeed almost like what I had intended in my previous mail.
>
> > * Would it be enough to have the files on a network share instead of
> rsync'ing them?
> > * Is it really needed to have Clang running on the remote machine? Would
> it be enough to have access to the included headers on remote?
>
> I think Network share you suggest is a good idea. It solves both of
> the above issues. With network sharing, we wouldn't need rsync and we
> wouldn't need to run clang on remote machine.
>
> I will refine my initial proposal and put forth a more detailed
> proposal considering your suggestions and more use-cases asap.
> If you have any other thoughts and suggestions, kindly let me know.
>

Hi,

I strongly suggest *not* to use network share. We tried that several years
ago (with SMB), and it was awful. Parsing takes forever over the network.
Working locally and using rsync before build works much better (once you
have ssh keys set up).

We have a local partial copy of the sysroot, which includes the include
directory, and the shared libraries that are linked with our application
(for each platform we support).

- Orgad
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

[Sree Gowtham Josyula]

Hi André & Everyone,

Thanks for showing interest in my suggestion. QTCREATORBUG-16246 is
indeed almost like what I had intended in my previous mail.

> * Would it be enough to have the files on a network share instead of 
> rsync'ing them?
> * Is it really needed to have Clang running on the remote machine? Would it 
> be enough to have access to the included headers on remote?

I think Network share you suggest is a good idea. It solves both of
the above issues. With network sharing, we wouldn't need rsync and we
wouldn't need to run clang on remote machine.

I will refine my initial proposal and put forth a more detailed
proposal considering your suggestions and more use-cases asap.
If you have any other thoughts and suggestions, kindly let me know.

Thank you.

Best Regards,
Gowtham
(Sree Gowtham Josyula)
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

[André Hartmann]

Hi Gowtham,

your proposal sounds indeed interesting. And we have the task 
QTCREATORBUG-16246, which almost looks like your suggestion.


So there *is* interest in this topic :)

I've just two comments to the implementation:

* Would it be enough to have the files on a network share instead of 
rsync'ing them?
* Is it really needed to have Clang running on the remote machine? Would 
it be enough to have access to the included headers on remote?


Best regards,
André

[1] https://bugreports.qt.io/browse/QTCREATORBUG-16246

Am 10.03.2018 um 21:15 schrieb Sree Gowtham Josyula:

Hello All,

This mail was initially posted in the Qt  Development mailing list
,
but I am reposting here, with minor edits, as the audience here are
more appropriate.

I am a Masters Student in Computer Engineering Program at Arizona
State University. I am interested in participating in Google Summer of
Code(GSoC) 2018 with Qt as my mentor organization. Link -
https://blog.qt.io/blog/2018/02/22/google-summer-of-code-2018/

In this mail, I would like to propose a new feature for Qt Creator as
my GSoC project, based on my experience at my previous company.

Issue faced in previous company -  In my previous company, we had our
development environment in Windows and target platform as arm-linux
machine. For that, we would develop code on Windows systems and then
sync the project/workspace to the remote linux server and then compile
with the cross-compilation tool-chain there and then deploy on the
target machine elsewhere.

In the above setup  we faced the following problems -
1. Unavailability of code completion frameworks on the development
machine as not all the platform headers were available locally
2. Frequently syncing the workspace was a wasteful of time

In order to solve the above problem, I would like to propose a "Remote
System Development Plug-in" for editing, compiling, executing &
debugging files on a remote system on the lines on Emacs Tramp package
(https://www.emacswiki.org/emacs/TrampMode).

High Level Features -

1. Public key registration of development machine on remote machine
(and vice-versa) for seamless syncing of files between the two
machines
2. Setting up a toolkit (Compiler, Debugger, Qt Tool-chain, cmake,
qmake, qbs, sysroot) of a remote machine on the Development machine's
Qt Creator IDE
3. Opening projects of remote machine in development machine (using
the same interface used for opening project on development machine)
4. Automatic syncing of workspace between development machine and
remote machine(on every save & periodically) - could be done using
rsync
5. Compilation of code on the remote machine with the tool-chain setup there
6. Execution & debugging code on Remote machine
7. Supporting Clang based code completion, got-definition &
refactoring - Might need to run a clang-daemon/Language Server on the
remote machine and send the responses to development machine.

Kindly let me know your thoughts about my above idea.

Best Regards,
Gowtham
(Sree Gowtham Josyula)
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator





--
Dipl.-Ing. (FH) André Hartmann
Softwareentwicklung / Software Development

E-Mail: andre.hartm...@iseg-hv.de | Tel: +49 351 26996-43 | Fax: +49 351 
26996-21


iseg Spezialelektronik GmbH - HIGH VOLTAGE. EXACTLY.
iseg-hv.de | iseg-hv.com | download.iseg-hv.com

Bautzner Landstr. 23, 01454 Radeberg / Rossendorf, Germany
Geschäftsführer / Managing directors: Dr. Frank Gleisberg, Dr. Joachim 
Pöthig

Amtsgericht / Lower district court: Dresden HRB 16250
Umsatzsteuer-Id: / VAT-ID: DE812508942

News / Information
https://iseg-hv.com/en/products/control#isegControl2 isegControl2 - 
Unified Control Software
https://iseg-hv.com/en/products/detail/EHS EHS FLEX - Customize and keep 
the price
https://iseg-hv.com/en/products/detail/EHS EHS STACK - Perfect for GEM 
Detectors
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf NEW! 
Product catalog 2017 / 2018 released
https://iseg-hv.com/en/products/detail/NHR NHR - NIM HV-Supply with 
reversible polarity


Links
https://www.linkedin.com/company/12726924 iseg on LINKEDIN | Let's stay 
connected!
https://www.youtube.com/channel/UC5AL-ZgOqSim_1gYNnndyzQ iseg on YOUTUBE 
| Tutorials and more ...

https://www.twitter.com/iseg_hv iseg on TWITTER | please follow!
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf iseg 
CATALOG | download product catalog as PDF
http://download.iseg-hv.com/ iseg DOWNLOADS | manuals, software, 
firmware and more...


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. Wenn Sie nicht der richtige
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren 
Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser Mail ist ni

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

[Sree Gowtham Josyula]

Hello All,

This mail was initially posted in the Qt  Development mailing list
,
but I am reposting here, with minor edits, as the audience here are
more appropriate.

I am a Masters Student in Computer Engineering Program at Arizona
State University. I am interested in participating in Google Summer of
Code(GSoC) 2018 with Qt as my mentor organization. Link -
https://blog.qt.io/blog/2018/02/22/google-summer-of-code-2018/

In this mail, I would like to propose a new feature for Qt Creator as
my GSoC project, based on my experience at my previous company.

Issue faced in previous company -  In my previous company, we had our
development environment in Windows and target platform as arm-linux
machine. For that, we would develop code on Windows systems and then
sync the project/workspace to the remote linux server and then compile
with the cross-compilation tool-chain there and then deploy on the
target machine elsewhere.

In the above setup  we faced the following problems -
1. Unavailability of code completion frameworks on the development
machine as not all the platform headers were available locally
2. Frequently syncing the workspace was a wasteful of time

In order to solve the above problem, I would like to propose a "Remote
System Development Plug-in" for editing, compiling, executing &
debugging files on a remote system on the lines on Emacs Tramp package
(https://www.emacswiki.org/emacs/TrampMode).

High Level Features -

1. Public key registration of development machine on remote machine
(and vice-versa) for seamless syncing of files between the two
machines
2. Setting up a toolkit (Compiler, Debugger, Qt Tool-chain, cmake,
qmake, qbs, sysroot) of a remote machine on the Development machine's
Qt Creator IDE
3. Opening projects of remote machine in development machine (using
the same interface used for opening project on development machine)
4. Automatic syncing of workspace between development machine and
remote machine(on every save & periodically) - could be done using
rsync
5. Compilation of code on the remote machine with the tool-chain setup there
6. Execution & debugging code on Remote machine
7. Supporting Clang based code completion, got-definition &
refactoring - Might need to run a clang-daemon/Language Server on the
remote machine and send the responses to development machine.

Kindly let me know your thoughts about my above idea.

Best Regards,
Gowtham
(Sree Gowtham Josyula)
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator