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

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

On 4/24/2018 9:52 AM, Jeff Johnston wrote:

<stuff deleted>

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

One of the first things a new autotools project does is to generate the makefile.   Since there is no container image assigned to the project upon creation, it can't do that (unless the environment/OS allows it to be done locally instead).   How is this to be handled?

With a remote connection (org.eclipse.remote) and an impl of IRemoteConnectionPropertyService via that connection (which would have to be implemented with...e.g. a simple script on the container to allow querying the env) upon project creation the hooks are used so that the makefile generation can be done via the remote (container).

For the container command launcher...would this be a matter of setting up the container command launcher upon project creation (e.g. via the project creation wizard) rather than via project properties?

<stuff deleted>

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.

WRT autotools I think the makefile generation done upon project construction (before image is assigned) is problematic, but I admit I haven't yet tried with the full environment described with latest code (side question: where is that latest, btw?).  Have there been any releases of the latest yet?

<stuff deleted>

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.

Not sure what you mean actual requirement.   Windows Eclipse/CDT/Docker -> Linux image with autotools available installed in the image, and creating a new CDT autotools project in workspace are the actual requirements.

Scott