Re: [cdt-dev] Wrapping CDT command invocation

[James Blackburn <jamesblackburn@xxxxxxxxx>]

Hi Ed,

Thanks for the detailed reply!

> We indeed came up with just the kind of framework you're asking for.  It provides interfaces for the way process parameters are collected (IProcessLauncherFactory) and for the way a process is created and launched (IProcessLauncher).  The process launcher yields a java.lang.Process from this, so from that point on, it's all standard Java.  We're able to use it for launching anywhere (host, sandbox, VM, device over SSH, etc).

CDT already has a CommandLauncher mechanism which can return a Process
for a given command line string, it's just not very flexible currently
-- i.e. all users of it need to provide their own mechanism of
choosing an appropriate ICommandLauncher.

What I'm thinking of is providing a centralised means via cdt.core of
delegating to a contributed ICommandLauncher.  It's clearly
straightforward to wrap command lines of the form I propose (i.e. ssh
somewhere and exec the same string) but I'm less certain of what
additional context custom ICommandLaunchers would need to be truly
useful / flexible.

The main places we use run external tools today is as part of the
build and during launch, so it'd be good if the mechanisms these CDT
components use to run commands is customizable.

> I'm not sure a general framework is even what's needed.  We found that such integration would have been really easy if the underlying code just exposed the whole process creation factory, e.g., provided a way to take a command line, a set of environment variable changes, and a current directory, and allowed an extender to provide a java.lang.Process from it.  Then an extender can pretty much do whatever s/he wants to under the covers, including rewriting the command line, adjusting environment variables, launching locally or remotely, etc.

That's what I'm proposing.

I've filed a bug on this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=279818
I'd appreciate feedback on this, including whether people think it's a
good / bad idea, as well as whether there's any additional context an
ICommandLauncher would need to perform the exec.  At the moment I'm
thinking 'type' of exec (build / launch) and IProject. Whether this is
sufficient to drive something like RDT executions on a remote box, I'm
not sure (although it already seems to use ICommandLauncher in its own
way :))...

James