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


On Mon, Apr 23, 2018 at 6:35 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
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?

I mean that Docker Tooling building in an existing running Container isn't currently in the Docker future feature plan.  Using Docker Tooling in Eclipse Windows to build in Linux Containers is supported, but each action will create, run, and then terminate a new Container based on whatever Image the user selects.  I hope that clarifies.  If you want to try to put together some solution that enhances Docker launch to additionally support using exec to run commands in an existing Container which will handle the header file syncing and project source mount (copy forward, copy changes back using the remote daemon logic), I'm open to see how well it works.  You might be fine with requiring the end-user to clear the header cache if they perform updates.  You'll also have to invalidate the ScannerInfo so that build macros etc.. get recalculated.


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

I just think the PTP model is a better fit because it already addresses a number of the problems that an existing running Container can present.  Feel free to disagree.
 

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?

I don't know.  I think it would be a question for the PTP folks.  They use org.eclipse.remote for supporting synchronized projects.


 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

Back to the top