Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] cdt, windows, and tools

I can answer #4. I have called off the move of org.eclipse.remote to CDT. Terminal was also going to move but that’s called off as well. The idea was to grow these two subprojects by making them part of the CDT. However, I started to notice I was the only one that really cared, or cared enough to do the work, so I put my effort towards other things that are less dependent on a hope and a prayer. 😉. It’s time for others to do that.

 

Doug.

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Scott Lewis
Sent: Monday, April 23, 2018 1:49 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] cdt, windows, and tools

 

Hi Jeff,

Thanks for the info.   I have some questions wrt the following use case:

Windows 10+ (running Eclipse C/C++ and docker engine) --> Linux running in Docker container

Assume for the moment that the Docker container is running localhost.   Also assume that ideally it would be possible to use any/all c/c++ toolchains available in Linux (autotools, make, cmake, etc) for development as well as eclipse-based run/debug, but for simplicity take autotools as the immediate focus.

As I understand it, the org.eclipse.remote API was created to enable eclipse-based development of remote projects (and/or synchronized/replicated projects).   As you say, hooks to use it are already in autotools (for ptp) and perhaps other types of projects.  I've taken a look at and played with ptp's remote project and synchronized project.

The org.eclipse.remote API allows the creation of 'connection providers'...that use different comm layers/transports for the inter-process interaction...e.g. ssh and a server-based one  for PTP (for synchronized projects).    It is possible to implement this API via the Linuxtools rest-based Docker API...e.g. [1].

Questions:

1) Does it make sense to use org.eclipse.remote to address the use case above (i.e. Windows tooling -> Linux container)?    Or is this use case in the plan for ContainerCommandLauncher and additions/enhancements through container command launcher;   Or not in your plan at all for C/C++ and Docker?

2) And of course there is the support of managed build-based projects (e.g. autotools), and core-build-based projects.   Is the answer to 1 going to be the same for both, some mixture, or something else?

3) One of the things that org.eclipse.remote seems to handle well, that is an area of confusion for me wrt to the container command launcher, is the use of system properties to configure the Eclipse-based C/C++ tooling/toolchain.   The org.eclipse.remote API has IRemoteConnectionPropertyService to allow the tooling to get the Docker container's environment (and perhaps other toolchain metadata) when setting up the project's build...and other...configuration.   It's my impression that this creates a problem/complexity in the Eclipse tooling support wrt the windows -> linux container use case.

4) org.eclipse.remote doesn't appear to be actively supported/developed by Ptp or TM anymore.  The comments on this bug [2] seem to suggest that org.eclipse.remote is going to move to cdt, which would imply that it's going to be used by cdt (for docker or not).

Thanks for any answers,

Scott

[1] http://git.yoctoproject.org/cgit/cgit.cgi/eclipse-yocto-contrib/tree/plugins/org.yocto.remote.docker/src/org/yocto/remote/docker?h=timo/remotedocker&id=5e5a59323a5b4399ee15e66f90d8da08609e4794

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=500768



On 4/19/2018 2:16 PM, Jeff Johnston wrote:

Sorry, I should have commented earlier.

Autotools remote support was originally added for PTP support.  If you look at the history of RemoteCommandLauncher,

you will see that Autotools support was originally added as part of:

Bug 430831 - add autotools support for PTP synchronized project

This originally supported PTP remote projects or local projects.

 

When I added initial Container build support, I modified RemoteCommandLauncher to use the CommandLauncherManager if not running remotely to

determine the default ICommandLauncher.  Autotools requested the RemoteCommandLauncher and this would end up figuring out the right ICommandLauncher to use.

Any testing of the remote Autotools support would be in PTP.

 

- Jeff J.

 

 

On Thu, Apr 19, 2018 at 4:14 PM, Scott Lewis <scottslewis@xxxxxxxxx> wrote:

On 4/11/2018 9:00 AM, Scott Lewis wrote:

Thanks for the info.

In autotools specifically, I've noticed the use of org.eclipse.remote API.   Two questions about the use of org.eclipse.remote:

1) Was it built in to some/all of the other toolchains?
2) Has it been tested/used for (e.g.) * -> linux remoting...with autotools specifically?   If it has been tested or used under such conditions, is there any code available as part of CDT or elsewhere?


Should I interpret the lack of response to this question as indicating that there are no actual impls/uses of org.eclipse.remote that have been tested with autotools?

Thanks,

Scott

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 




_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


Back to the top