Re: [cdt-dev] cdt, windows, and tools

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

On 4/23/2018 1:44 PM, Jeff Johnston wrote:

<stuff deleted>

I assume we are talking about connecting to a live Container set up to continuously run Linux.  This is basically a VM/remote system scenario and IMO, is best handled by PTP.  I also assume you do not want to set up Eclipse to run in the Container and display on the host (e.g. using vnc server or X11 ssh).

That's right.

 

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?

If you are referring to PTP and using org.eclipse.remote to address the use case, I would say yes, unless you are going to put restrictions on the end-user or add more overhead.  This scenario has never been in the plan for CDT Docker support. 

To make sure I understand...you mean Windows Eclipse -> Linux docker container is not in the CDT Docker support plan?

The CDT Container build and Docker Launching API in Docker Tooling is taking advantage of assumptions that can only be made with a fresh Container that we start and control.  A fresh Container can't change its headers unless the end-user mounts on top of system dirs which isn't supported anyway.  The static headers allows the design to copy headers to the host (one-time) and perform indexing locally.  If dealing with a live Container, the end-user could install new software on the fly, update software, or even delete software.  Any caching of headers now has sync issues to resolve.  This open-end scenario is best handled by PTP which runs the build/indexing remotely. 

You seem to be suggesting that the Windows Eclipse -> Linux container use case would be best handled by using org.eclipse.remote (how PTP does things).

By your and Doug's responses, it seems that the Windows Eclipse host -> localhost Linux docker container is not going to be supported via the existing docker tooling, and so you seem to be pointing to the org.eclipse.remote for at least managed build.   But at the same time org.eclipse.remote is being moved away from (Doug's response to 4) and isn't really being worked on/supported anymore (e.g. extensions for core build) which makes it somewhat unattractive to build upon, especially given it's somewhat complicated.

Does this mean that Windows Eclipse -> Linux docker container use case/scenario (for managed build and/or core build) effectively isn't going to be supported?

Scott