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 1:48 PM, Scott Lewis <scottslewis@xxxxxxxxx> wrote:
Hi Jeff,

Thanks for the info.   I have some questions wrt the following use case:

Windows 10+ (running Eclipse C/C++ and docker engine) --> Linux running in Docker container

Assume for the moment that the Docker container is running localhost.   Also assume that ideally it would be possible to use any/all c/c++ toolchains available in Linux (autotools, make, cmake, etc) for development as well as eclipse-based run/debug, but for simplicity take autotools as the immediate focus.

As I understand it, the org.eclipse.remote API was created to enable eclipse-based development of remote projects (and/or synchronized/replicated projects).   As you say, hooks to use it are already in autotools (for ptp) and perhaps other types of projects.  I've taken a look at and played with ptp's remote project and synchronized project.

The org.eclipse.remote API allows the creation of 'connection providers'...that use different comm layers/transports for the inter-process interaction...e.g. ssh and a server-based one  for PTP (for synchronized projects).    It is possible to implement this API via the Linuxtools rest-based Docker API...e.g. [1].

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

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.  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.  Now, one could theoretically restrict the user's support to headers seen at first compilation.  This means the user would either have to refrain from updating or else the cache would have to be wiped out after updates.  To detect this programatically is probably doable, but would require some work and add overhead to the build to discover.

A second assumption is that needed/dynamic files can easily be mounted in the fresh Container (e.g. we just mount the project directory and have access to all the source files as well as having the build files available after the Container ends).  For a live Container, we would have to do a copy to the Container and a copy back to handle file system updates.  This method is currently used for remote containers whereby a mount isn't possible.  Not ideal, but remote daemons aren't the norm and we have fresh Container at our disposal so there isn't any synchronization issues to deal with.  In the local case, the mount is extremely fast and requires little from us.  For file synchronization, PTP has built a fast system based upon git.

Without using PTP, the Docker exec method would have to be used to run commands in the live Container.


2) And of course there is the support of managed build-based projects (e.g. autotools), and core-build-based projects.   Is the answer to 1 going to be the same for both, some mixture, or something else?


I don't know if PTP supports core-build-based projects yet.  The answer is probably no as the model is new.  This generates more decisions (e.g. update PTP / Core-build?).
 
3) One of the things that org.eclipse.remote seems to handle well, that is an area of confusion for me wrt to the container command launcher, is the use of system properties to configure the Eclipse-based C/C++ tooling/toolchain.   The org.eclipse.remote API has IRemoteConnectionPropertyService to allow the tooling to get the Docker container's environment (and perhaps other toolchain metadata) when setting up the project's build...and other...configuration.   It's my impression that this creates a problem/complexity in the Eclipse tooling support wrt the windows -> linux container use case.


My latest changes to the Core model now use the /usr/bin/env command to run build commands with the Container's env and also allow the user to override any env-var per command.  This doesn't address polling of the environment, but for many builds, overriding as needed should be enough (e.g. point an env-var to the installed x product's location).  Polling would have to run a container and cache the results if this is absolutely needed (e.g. visualizing the current environment before changing it).

4) org.eclipse.remote doesn't appear to be actively supported/developed by Ptp or TM anymore.  The comments on this bug [2] seem to suggest that org.eclipse.remote is going to move to cdt, which would imply that it's going to be used by cdt (for docker or not).


Doug has answered this.
 
Thanks for any answers,

Scott

[1] http://git.yoctoproject.org/cgit/cgit.cgi/eclipse-yocto-contrib/tree/plugins/org.yocto.remote.docker/src/org/yocto/remote/docker?h=timo/remotedocker&id=5e5a59323a5b4399ee15e66f90d8da08609e4794

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=500768



On 4/19/2018 2:16 PM, Jeff Johnston wrote:
Sorry, I should have commented earlier.

Autotools remote support was originally added for PTP support.  If you look at the history of RemoteCommandLauncher,
you will see that Autotools support was originally added as part of:

Bug 430831 - add autotools support for PTP synchronized project

This originally supported PTP remote projects or local projects.

When I added initial Container build support, I modified RemoteCommandLauncher to use the CommandLauncherManager if not running remotely to
determine the default ICommandLauncher.  Autotools requested the RemoteCommandLauncher and this would end up figuring out the right ICommandLauncher to use.

Any testing of the remote Autotools support would be in PTP.

- Jeff J.


On Thu, Apr 19, 2018 at 4:14 PM, Scott Lewis <scottslewis@xxxxxxxxx> wrote:
On 4/11/2018 9:00 AM, Scott Lewis wrote:
Thanks for the info.

In autotools specifically, I've noticed the use of org.eclipse.remote API.   Two questions about the use of org.eclipse.remote:

1) Was it built in to some/all of the other toolchains?
2) Has it been tested/used for (e.g.) * -> linux remoting...with autotools specifically?   If it has been tested or used under such conditions, is there any code available as part of CDT or elsewhere?

Should I interpret the lack of response to this question as indicating that there are no actual impls/uses of org.eclipse.remote that have been tested with autotools?

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



_______________________________________________
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



_______________________________________________
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