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 7:44 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
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.

Most of the autotool outputs are scripts and are run in the container using the sh -c command.  This will pick up the default shell environment for the Container including the default path.  Remember that we are using a fresh container so there isn't any other environment source other than additional/overriding environment vars from the user which can be specified as part of the configure settings dialog.  For the new core build, we use the env command to allow overriding of environment per command and have UI to allow setting environment (e.g. manual ninja call has environment text widget and an options text widget).

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.

If Windows Linux container is based on a Linux Image that is accessible by the Docker Daemon, it should just work.  It just won't work if the user starts such a Container and requires you to build within it (e.g. user adds packages that are needed by the build but aren't part of the original image).  If the Linux image has all the tools needed, there shouldn't be an issue using it like any other Docker Image.

 

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?

It might be.  It depends on what the actual requirement is you are basing this request on.

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


Back to the top