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].
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?
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?
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.
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).
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: