[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
<http://lists.qt-project.org/pipermail/development/2018-March/032301.html>,
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)

[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

Post by Sree Gowtham Josyula
Hello All,
This mail was initially posted in the Qt Development mailing list
<http://lists.qt-project.org/pipermail/development/2018-March/032301.html>,
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
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

E-Mail: ***@iseg-hv.de | Tel: [phone] | 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 nicht
gestattet.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient
(or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.

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

[Orgad Shaneh]

On Mon, Mar 12, 2018 at 1:38 PM, 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.

Post by André Hartmann
* Would it be enough to have the files on a network share instead of

rsync'ing them?

Post by André Hartmann
* 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

[Konstantin Tokarev]

Post by 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.

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

[Harri Pasanen]

Post by Konstantin Tokarev

Post by 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.

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

[Orgad Shaneh]

Post by André Hartmann

Post by Konstantin Tokarev

Post by Orgad Shaneh
On Mon, Mar 12, 2018 at 1:38 PM, 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.

Post by André Hartmann
* Would it be enough to have the files on a network share instead of

rsync'ing them?

Post by Konstantin Tokarev

Post by Orgad Shaneh

Post by André Hartmann
* 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?

Post by Konstantin Tokarev

Post by Orgad Shaneh

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

Post by Konstantin Tokarev

Post by Orgad Shaneh
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).

Post by Konstantin Tokarev
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

[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

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh
On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula

Post by 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.

Post by André Hartmann
* 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

[Eike Ziller]

Post by 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?

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

Post by Sree Gowtham Josyula

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh
On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula

Post by 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.

Post by André Hartmann
* 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
http://lists.qt-project.org/mailman/listinfo/qt-creator

--
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
***@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

[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-***@qt.io
[phone]
http://qt.io

-----Original Message-----
project.org] On Behalf Of Eike Ziller
Sent: Dienstag, 13. März 2018 10:00
Subject: Re: [Qt-creator] GSoC 2018: New feature proposal for Qt Creator

On Mar 13, 2018, at 09:54, 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?

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

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh
On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula

Post by Sree Gowtham Josyula
Hi André & Everyone,
Thanks for showing interest in my suggestion. QTCREATORBUG-16246

is

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh

Post by Sree Gowtham Josyula
indeed almost like what I had intended in my previous mail.

Post by André Hartmann
* 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?

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh

Post by Sree Gowtham Josyula
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

Post by Orgad Shaneh
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
http://lists.qt-project.org/mailman/listinfo/qt-creator

--
Eike Ziller
Principal Software Engineer
The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
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
http://lists.qt-project.org/mailman/listinfo/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

Post by 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
[phone]
http://qt.io

-----Original Message-----
project.org] On Behalf Of Eike Ziller
Sent: Dienstag, 13. März 2018 10:00
Subject: Re: [Qt-creator] GSoC 2018: New feature proposal for Qt Creator

On Mar 13, 2018, at 09:54, 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?

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

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh
On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula

Post by Sree Gowtham Josyula
Hi André & Everyone,
Thanks for showing interest in my suggestion. QTCREATORBUG-16246

is

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh

Post by Sree Gowtham Josyula
indeed almost like what I had intended in my previous mail.

Post by André Hartmann
* 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?

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh

Post by Sree Gowtham Josyula
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

Post by Orgad Shaneh
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
http://lists.qt-project.org/mailman/listinfo/qt-creator

--
Eike Ziller
Principal Software Engineer
The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
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
http://lists.qt-project.org/mailman/listinfo/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

Post by 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

Post by 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
[phone]
http://qt.io

-----Original Message-----
project.org] On Behalf Of Eike Ziller
Sent: Dienstag, 13. März 2018 10:00
Subject: Re: [Qt-creator] GSoC 2018: New feature proposal for Qt Creator

On Mar 13, 2018, at 09:54, 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?

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

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh
On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula

Post by Sree Gowtham Josyula
Hi André & Everyone,
Thanks for showing interest in my suggestion. QTCREATORBUG-16246

is

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh

Post by Sree Gowtham Josyula
indeed almost like what I had intended in my previous mail.

Post by André Hartmann
* 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?

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh

Post by Sree Gowtham Josyula
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

Post by Orgad Shaneh
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
http://lists.qt-project.org/mailman/listinfo/qt-creator

--
Eike Ziller
Principal Software Engineer
The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
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
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

[Sree Gowtham Josyula]

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?

Thanks.

Best Regards,
Sree Gowtham J

Best Regards,
Sree Gowtham Josyula
Mobile: [phone]

Post by 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

Post by 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

Post by 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
[phone]
http://qt.io

-----Original Message-----
project.org] On Behalf Of Eike Ziller
Sent: Dienstag, 13. März 2018 10:00
Subject: Re: [Qt-creator] GSoC 2018: New feature proposal for Qt Creator

On Mar 13, 2018, at 09:54, 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?

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

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh
On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula

Post by Sree Gowtham Josyula
Hi André & Everyone,
Thanks for showing interest in my suggestion. QTCREATORBUG-16246

is

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh

Post by Sree Gowtham Josyula
indeed almost like what I had intended in my previous mail.

Post by André Hartmann
* 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?

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Konstantin Tokarev

Post by Orgad Shaneh

Post by Sree Gowtham Josyula
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

Post by Orgad Shaneh
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
http://lists.qt-project.org/mailman/listinfo/qt-creator

--
Eike Ziller
Principal Software Engineer
The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
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
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

[Orgad Shaneh]

On Wed, Mar 21, 2018 at 10:32 PM, Sree Gowtham Josyula <

Post by Sree Gowtham Josyula
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):

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

[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: [phone]

Post by Orgad Shaneh
On Wed, Mar 21, 2018 at 10:32 PM, Sree Gowtham Josyula

Post by Sree Gowtham Josyula
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
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
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
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

[Ariel Molina]

Hi,

I see you are inclined to do VFS on QtC. Would you be interested in
properly patching and improving the QRC system in QtC? There are several
improvements to be done.

Also, there are huge fixes on QMLPuppet and QML editor that would be
awesome to have, like proper picking, proper smart alignment and even
patches to live editing.

Ariel

On Wed, Mar 21, 2018 at 2:32 PM, Sree Gowtham Josyula <

Post by Sree Gowtham Josyula
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?
Thanks.
Best Regards,
Sree Gowtham J
Best Regards,
Sree Gowtham Josyula
Mobile: [phone]

Post by 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

Post by 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

Post by Tobias Hunger

Post by Sree Gowtham Josyula
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

Post by Tobias Hunger

Post by Sree Gowtham Josyula
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

Post by Riitta-Leena Miettinen
Hello,

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

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen
Leena
------------------------------------------------------------

----------------------------------------------------------

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen
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

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen
[phone]
http://qt.io

-----Original Message-----
From: Qt-creator [mailto:qt-creator-bounces+riitta-leena.miettinen
project.org] On Behalf Of Eike Ziller
Sent: Dienstag, 13. MÀrz 2018 10:00
Subject: Re: [Qt-creator] GSoC 2018: New feature proposal for Qt

Creator

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

On Mar 13, 2018, at 09:54, 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

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

as the remote compiler when queried with -v and -dM flags? What is

its

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

significance?

In Qt Creator settings (Build & Run > Compilers > Add > Custom) you

can create

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

a “custom” compiler, manually specifying ABI, predefined macros,

system

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

include paths etc.
Then you can set that as a compiler for the kit, to make code

completion work

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

with these values.
Br, Eike

Post by Orgad Shaneh

Post by Harri Pasanen

On Mar 12, 2018, at 4:32 PM, Konstantin Tokarev <

Post by Orgad Shaneh
On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula

Hi André & Everyone,
Thanks for showing interest in my suggestion.

QTCREATORBUG-16246

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

is

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh

indeed almost like what I had intended in my previous mail.

Post by André Hartmann
* Would it be enough to have the files on a network share

instead of

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh

Post by André Hartmann
rsync'ing them?
* Is it really needed to have Clang running on the remote

machine?

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh

Post by André Hartmann
Would it be enough to have access to the included headers on

remote?

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh

I think Network share you suggest is a good idea. It solves

both of

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh

the above issues. With network sharing, we wouldn't need rsync

and we

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh

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.

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh
Hi,
I strongly suggest not to use network share. We tried that

several

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh
years ago (with SMB), and it was awful. Parsing takes forever

over the

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh
network. Working locally and using rsync before build works

much better

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh
(once you have ssh keys set up).
We have a local partial copy of the sysroot, which includes the

include

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh
directory, and the shared libraries that are linked with our

application

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh
(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

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh

Post by Harri Pasanen
server.
Also, one cannot copy locally the toolchain if the server is

different OS,

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh

Post by Harri Pasanen
unless a cross compilation environment is setup, which in itself

is a major

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh

Post by Harri Pasanen
piece of work.

That's right. What we did was to create dummy compilers that

return the

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

same

Post by Orgad Shaneh
values as the real compiler when called with -v and -dM etc. This

is no

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh
longer needed, as a "custom compiler" can be created instead.
I suggest to read the values from the remote compiler, and create

a local

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh
custom compiler with the same values (except include directories

which

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

Post by Orgad Shaneh
should be adapted to the local sysroot location).
- Orgad

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

--
Eike Ziller
Principal Software Engineer
The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
http://qt.io
GeschÀftsfÌhrer: Mika PÀlsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht

Charlottenburg, HRB

Post by Tobias Hunger

Post by Sree Gowtham Josyula

Post by Riitta-Leena Miettinen

144331 B
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

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

[Sree Gowtham Josyula]

Hi Ariel,

Thanks for the suggestion.
Actually, I have been keen on implementing the VFS plugin from my job
in my previous company where we had many issues in supporting multiple
platforms. It will be good if you could share the ticket details for
the issues you have mentioned so that I can understand the problem
better.

Best Regards,
Sree Gowtham J

Hi,
I see you are inclined to do VFS on QtC. Would you be interested in properly
patching and improving the QRC system in QtC? There are several improvements
to be done.
Also, there are huge fixes on QMLPuppet and QML editor that would be awesome
to have, like proper picking, proper smart alignment and even patches to
live editing.
Ariel
On Wed, Mar 21, 2018 at 2:32 PM, Sree Gowtham Josyula

Post by Sree Gowtham Josyula
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?
Thanks.
Best Regards,
Sree Gowtham J
Best Regards,
Sree Gowtham Josyula
Mobile: [phone]

Post by 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

Post by 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

Post by Riitta-Leena Miettinen
Hello,
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
[phone]
http://qt.io

-----Original Message-----
From: Qt-creator
project.org] On Behalf Of Eike Ziller
Sent: Dienstag, 13. März 2018 10:00
Subject: Re: [Qt-creator] GSoC 2018: New feature proposal for Qt Creator

On Mar 13, 2018, at 09:54, 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?

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

Post by Orgad Shaneh

Post by Harri Pasanen

On Mar 12, 2018, at 4:32 PM, Konstantin Tokarev

Post by Orgad Shaneh
On Mon, Mar 12, 2018 at 1:38 PM, Sree Gowtham Josyula

Post by Sree Gowtham Josyula
Hi André & Everyone,
Thanks for showing interest in my suggestion.
QTCREATORBUG-16246

is

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh

Post by Sree Gowtham Josyula
indeed almost like what I had intended in my previous mail.

Post by André Hartmann
* 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?

Post by Orgad Shaneh

Post by Harri Pasanen

Post by Orgad Shaneh

Post by Sree Gowtham Josyula
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

Post by Orgad Shaneh
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
http://lists.qt-project.org/mailman/listinfo/qt-creator

--
Eike Ziller
Principal Software Engineer
The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
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
http://lists.qt-project.org/mailman/listinfo/qt-creator

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

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

--
Ariel Molina R.
Oficina: [phone]
Movil: [phone]
http://edis.mx