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 4/23/2018 3:56 PM, Jeff Johnston wrote:
<stuff deleted>

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.

Yes it does.   FWIW, I understand the create, run, terminate and don't really mean to deviate from that unless required.  

What I don't understand about the Docker Tooling wrt the Eclipse Windows -> Linux container scenario is:   how each toolchain will handle the two environments (i.e. Windows and Linux).   For example:   when an autotools project is created one of the first things it does to setup is to consult the system environment (e.g. path, etc) prior to generating makefile, etc.    In autotools, and org.eclipse.remote enabled, this uses/hooks into the IRemoteConnectionPropertyService to get the path and etc from the remote (i.e. Linux container), rather than getting it from the (windows) system environment.

WRT autotools, hooks like this (system properties/values from remote) were what got me interested in using org.eclipse.remote...especially since at least the property service hooks are built into autotools.

<stuff deleted>
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.

I don't disagree.   But what I'm interested in isn't necessarily running in an existing container, but just the Windows Eclipse -> Linux container use case.

 

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.

So backing up....you say above that the Windows Eclipse -> Linux container is supported...with the create, run, terminate container approach.   Maybe this works with what's there and all about org.eclipse.remote is moot.   Has anyone tried/tested creating an autotools project with winEclipse pointed at autotools enabled linux image?

Thanks,

Scott


Back to the top