Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Wrapping CDT command invocation

Hi James,

I don't think there's a generic way to do this (yet).  We ran into the same issue in our Maemo Eclipse integration project (using Scratchbox, which has a similar command-line rewriting pattern, and also has to launch on a VM in some hosts).  

Unfortunately, most plugins encapsulate the way they both create the command lines and create and launch processes.  This means usually we had to write our own builders, launch support, debugger integration, etc. for this, since everything we depended on assumes it's launching locally with the original command line.

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

Our framework isn't really a general solution, though, since it's an adaptation layer on top of Eclipse, not something underneath it.  We can use it in our own plugins fine, but integrating with existing Eclipse plugins usually requires patches or overrides or just plain rewriting.  

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.  

We were able to get a patch into DSF to do this, so we can launch gdb[server] how we want, which helped a lot.  As for the rest, we had to write a custom Make builder and our own launch/debug plugins mostly from scratch.

-- Ed

-----Original Message-----
From: James Blackburn [mailto:jamesblackburn@xxxxxxxxx] 
Sent: Wednesday, June 10, 2009 8:31 AM
To: CDT General developers list.; ptp-user@xxxxxxxxxxx
Subject: [cdt-dev] Wrapping CDT command invocation

Hi All,

I'm currently looking into the best way to transparently wrap CDT command invocation so that I can tweak the command before invoking it.
 The reason is I'd like to prepend 'bsub -I <command>' to submit the commands to a LSF queue, though you could imagine using 'ssh / rsh' to cause the command to be executed on another machine.  I imagine this is the sort of thing that RDT needs to do as well.

I've seen 'CommandLauncher' though this only appears to be used by build.  I also found a presentation detailing RDT's service model, but I can't quite figure out how this fits into CDT (if it does at all).
Ideally my process runner wrapper would be othogonal to Building or Launching. The user would have some UI to control which long running tasks they wanted to wrap, which could be set at the Workspace or Project scope. They would have one place where they could configure their command wrapper, the running of which would be transparent to the component executing the external tool.

Is there a clean way of doing this already?  Is there some mechanism / project that I've missed that adds this functionality?

Any pointers greatly appreciated.


Back to the top