KDE-Forum.org

Ok... So I have been using KDE for a long time now and find it a very productive work environment. I have however hit a wall with a new problem. I want to use my version of kdevelop to edit my source code which is sitting on a remote server. Now of course I can open it using the fish KIO_slave but that limits my functionality since I can not actually call the compiles from my kdevelop since it will try to execute it from here. The build environment is very complicated on the remote system and does not correspond to a standard gnu/gcc type env, we dont even use automake. Anyway... To the idea...

So, I can remotely mount the filesystem using sshfs which will make it look more local but now the issue rests with running gmake. So, enter KomunicationKonduits. What if there existed a wrapper that would encapsulate calls like system, exec, and so forth, such that it ran the call remotely and then passed the exit code and the output back to the local system. The class could have several different backends corresponding to different low level communications protocols, the initial of course being the ssh and local backends. The class could hold a persistant connection open so that if any environment (ie. the build environment) can be maintained. So.. Instead of calling a program like the following:

int ret = system("gmake myanalysis.all");

One would use the following...

int ret = konduit.system("gmake.myanalysis.all");

Where konduit was of type KomunicationKonduitSSH. Is this crazy?
This could be used in any application that needs to call third party apps.

Justace

I started to play with just this idea. I agree it could easily get confusing. The problem is with the output redirection. I just can not seem to get past it. I was trying to hack something together locally here to play with but had to get back to work. It is simple really... For each third party app include this backend you want to use and the command. Pretty stright forward. The system would default to local which would essentially be a pass through.

I was waiting for somebody to mention remote X. Well, that is just not an option. The remote environment is locked down and I has very old software on it. To get the features of the new kdevelop I would have to install an entire kde tree there (well only kdelibs and kdebase + devel tools) but still you get the idea. It would be quite a chore and then this idea came to me as a possible solution.

Justace

Ok, one thing that should be stressed is that my remote build environment requires and expensive, as in time and resources, setup each time you log in. So I need something persistant. So, maybe I really just need to hack something together. I just thought that if there was a backend builtin for something like this it would be cool and might bennefit others.