Version: 3.0.0b2 (using KDE 3.1.4) Installed from: compiled sources Compiler: gcc version 3.2.2 OS: SunOS (sun4u) release 5.8 I tried to import a project from a network host (sftp://user@host) and was allowed to choose the complete path in "Choose directory to import"-dialog. OK-button: "You have to choose a directory." :( I only got ssh access to this host ... using vi again would be rather hard - I learned to love kdevelop :) This just a problem of this dialog - or a more principle one?
"Import" attempts to create a project in the given directory. For most (probably all) project types this won't work as the tools KDevelop fronts cannot work on remote files. In short, KDevelop only supports local filesystem projects (or NFS, but that is not recommended). Or do I misunderstand your report?
No, I don't think you misunderstand me. I'm using kdevelop successfully and without any problems locally and with filesystems mounted via NFS. Here again what I tried to do - in more words: I was granted ssh access to a host where some tools of significance used in my field of research are developed. I checked out these tools from cvs and tried to grasp the interaction of classes and files. As to expect: I failed. I am still as confused as I was before. Next idea: why not using the class browser and all these other features and goodies kdevelop provides instead of grep and less? Project -> Import -> Custom C++ Makefiles
Hmm.. if you have ssh (and cvs?) access to the machine with the source, why not simply copy the source to your local box (using for instance fish:/ in konqueror) and then create a project locally? I half think the real bug here is that the filedialog fools you into believing that remote source is supported, which it isn't for most (all?) languages. Maybe it does already make sense for some project types (PHP?) but I don't know. Altering KDevelop to "transparently" support remote source for most project types would be a MAJOR undertaking, and one I'm personally not convinced is recommendable at this point. Changing to LATER and hoping for some more discussion about this one.
As obvious your suggestion is, it's not that easy. Additional to problems concerning copyrights and things like that, the build process is really _custom_. To get a full build on my boxes *ouh* ... this may take a while (various libraries and includes, even a tool chain I never used before). In the meantime I copied the files I'm most interested in on my local box, syncing edited files by hand. > I half think the real bug here is that the filedialog fools you into > believing that remote source is supported, I agree with this. > support remote source for most project types Why not adding a new project type(s) "Remote (C/C++/...) Project" or something similar? The first step could be to disable anything not related to files. Then re-add the features step by step as solutions are available - without changing anything of the current Import-Project-Setup?!
Reopen, because the REMIND state "hides" the bug
*** Bug 75630 has been marked as a duplicate of this bug. ***
Heh. This one is still open? Well.. it is WISH for sure!
*** Bug 108015 has been marked as a duplicate of this bug. ***
I reported a dup of this bug and "Amilcar do Carmo Lucas" commented there: > This is a duplicate. > > And it will probably be closed as wontfix. > > AFAIK the line does not work: > gcc -c sftp://blabla.com/bla.c > > And unless you "fix" gcc it never will I can see the point if you use kdevelop only for c/c++ but I'm using kdevelop for Perl. We have a development server with apache and mod_perl installed on it, with identical setup as the production servers. It's not possible to do development on my own box because I use a different distribution with different versions of apache, mod_perl, etc. So it would be very handy for me to be able to develop directly on the development server. I think it's not a complex fix because kdevelop supports the sftp:// prefixes in the file browser, and it can open existing projects on sftp locations. It can also be an improvement for c++ developers. Of course they have to run 'make' on the other computer then. kdevelop can always show a warning/error saying something like: "cannot compile project at remote location".
Hi, I've tried also with smb service but also fail. i've solved the problem using NFS mount. It seems to work well regards strozzino
kdev4 supports remote projects - or rather the general API's do. The various implemented plugins usually don't (particularly buildtools, c++ support, grepview and so on).