Thread: [cedet-semantic] Cedet over tramp
Brought to you by:
zappo
From: Suvayu A. <fat...@gm...> - 2009-09-09 02:43:09
|
Hi all, Earlier used to parsing of my header files by putting something like this in my .emacs > (setq athena "/ssh:su...@re...:~suvayu/athena/Package") > (semantic-add-system-include athena 'c++-mode) > (add-to-list 'auto-mode-alist (cons athena 'c++-mode)) > (add-to-list 'semantic-lex-c-preprocessor-symbol-file (concat athena "/src")) > (add-to-list 'semantic-lex-c-preprocessor-symbol-file (concat athena "/include")) I got this from one of the popular howtos for CEDET. But now this fails to work after I rebuilt the latest CEDET from the cvs repositories. I tried to customize the variable `semantic-c-dependency-system-include-path' by putting in the path to the remote server as above, but that didn't work. It works for a local folder though. Is there a way to get around this? Since we are at it, I would also like to know whether it is possible to setup this include path based on environment variables as I have some other directories that I would like to parse which are determined by some environment variables in my shell. I am using Scientific Linux 4 on the remote machine and Fedora 11 on the local machine. Login shell for both machines is bash. Thanks in advance for any help on this. -- Suvayu Open source is the future. It sets us free. |
From: David E. <de...@ra...> - 2009-09-09 11:21:40
|
Suvayu Ali <fat...@gm...> writes: > Earlier used to parsing of my header files by putting something like > this in my .emacs > >> (setq athena "/ssh:su...@re...:~suvayu/athena/Package") >> (semantic-add-system-include athena 'c++-mode) Only those two should be necessary. >> (add-to-list 'auto-mode-alist (cons athena 'c++-mode)) Should not be needed if the files have correct extensions or header lines. >> (add-to-list 'semantic-lex-c-preprocessor-symbol-file (concat athena "/src")) >> (add-to-list 'semantic-lex-c-preprocessor-symbol-file (concat athena "/include")) Does not work, since semantic-lex-c-preprocessor-symbol-file needs files, not directories. But those lines shouldn't be needed, anyway. > But now this fails to work after I rebuilt the latest CEDET from the cvs > repositories. I tried to customize the variable > `semantic-c-dependency-system-include-path' by putting in the path to > the remote server as above, but that didn't work. It works for a local > folder though. What exactly does not work? If it fails to find the includes, please do a right-click on the #include line and choose "What is this". You can also list all unknown includes and add paths to the system include path there. Please also make sure that you can visit the files in a buffer via Tramp without any problems or need for authentication. If completions do not work, use M-x semantic-analyze-debug-assist to get a more verbose output. I just tried parsing a library via Tramp with the latest CVS, and it worked. > Is there a way to get around this? Since we are at it, I would also like > to know whether it is possible to setup this include path based on > environment variables as I have some other directories that I would like > to parse which are determined by some environment variables in my shell. Currently it will only try to set the include path based on the gcc installation. Which environment variables would need to be parsed? Regards, David |
From: Suvayu A. <fat...@gm...> - 2009-09-09 18:16:38
|
Hi David, Firstly, thank you for the detailed reply. David Engster wrote: > Suvayu Ali <fat...@gm...> writes: >> Earlier used to parsing of my header files by putting something like >> this in my .emacs >> >>> (setq athena "/ssh:su...@re...:~suvayu/athena/Package") >>> (semantic-add-system-include athena 'c++-mode) > > Only those two should be necessary. > That works. Looks like I was probably having some network problems and it happened to coincide with my compiling the latest CEDET. :P Extremely sorry for the noise. > If completions do not work, use > > M-x semantic-analyze-debug-assist > > to get a more verbose output. > Thanks a lot for this tip. I am relatively new to emacs and CEDET so still learning. :) >> Is there a way to get around this? Since we are at it, I would also like >> to know whether it is possible to setup this include path based on >> environment variables as I have some other directories that I would like >> to parse which are determined by some environment variables in my shell. > > Currently it will only try to set the include path based on the gcc > installation. Which environment variables would need to be parsed? > I work with a framework written in C++. While submitting the jobs we use various python scripts as job options. All this is managed by a "Configuration Management Tool" or CMT.[1] CMT uses various non-standard environment variables defined through shell functions in my .bashrc to look for other packages. I would like to add the path to a special package which is _not_ part of the framework. It is defined by a variable called $ROOTSYS, but only after I setup my environment using a shell function. Is it possible for CEDET to look at that since I am editing with tramp? If that is too complicated, is hard coding the path my only option? > Regards, > David > Thanks again for the help David. [1]http://www.cmtsite.org/ -- Suvayu Open source is the future. It sets us free. |
From: David E. <de...@ra...> - 2009-09-09 18:42:43
|
Suvayu Ali <fat...@gm...> writes: > That works. Looks like I was probably having some network problems and > it happened to coincide with my compiling the latest CEDET. :P Extremely > sorry for the noise. No problem. :-) > CMT uses various non-standard environment variables defined through > shell functions in my .bashrc to look for other packages. I would like > to add the path to a special package which is _not_ part of the > framework. It is defined by a variable called $ROOTSYS, but only after I > setup my environment using a shell function. Is it possible for CEDET to > look at that since I am editing with tramp? I'm afraid I do not really understand your setup. But maybe we can figure this out anyway. Where are these variables defined - on your machine or on the remote one? Adding a path from a local environment variable to the system include path is straightforward: (semantic-add-system-include (getenv "ROOTSYS") 'c++-mode) Does that help in any way? -David |
From: David E. <de...@ra...> - 2009-09-09 20:51:53
|
Suvayu Ali <fat...@gm...> writes: > David Engster wrote: >> I'm afraid I do not really understand your setup. But maybe we can >> figure this out anyway. Where are these variables defined - on your >> machine or on the remote one? > > They are defined in my .bashrc on the remote machine. The shell function > sources some scripts in my work area on the remote machine to get these > setup. OK, then you need a little helper function to retrieve the environment variable via ssh. This should do the job: (defun DE-get-remote-variable (variable server) "Get remote environment VARIABLE from SERVER via ssh&bash." (with-temp-buffer (call-process "/usr/bin/ssh" nil t nil server "bash" "-i" "-c" "env") (if (re-search-backward (format "^%s=\\(.*\\)" variable) nil t) (match-string 1) nil))) Hmm. Maybe you can also do this with tramp. I don't know. Anyway, now you can use (semantic-add-system-include (DE-get-remote-variable "ROOTSYS" "server.example.com") 'c++-mode) If you need to specify the user name, just use "user@server" or put a proper server definition into .ssh/config. Regards, David |
From: Suvayu A. <fat...@gm...> - 2009-09-09 23:16:31
|
Hi David, David Engster wrote: > Suvayu Ali <fat...@gm...> writes: >> David Engster wrote: >>> I'm afraid I do not really understand your setup. But maybe we can >>> figure this out anyway. Where are these variables defined - on your >>> machine or on the remote one? >> They are defined in my .bashrc on the remote machine. The shell function >> sources some scripts in my work area on the remote machine to get these >> setup. > > OK, then you need a little helper function to retrieve the environment > variable via ssh. This should do the job: > > (defun DE-get-remote-variable (variable server) > "Get remote environment VARIABLE from SERVER via ssh&bash." > (with-temp-buffer > (call-process "/usr/bin/ssh" nil t nil server "bash" "-i" "-c" "env") > (if (re-search-backward (format "^%s=\\(.*\\)" variable) nil t) > (match-string 1) > nil))) > > Hmm. Maybe you can also do this with tramp. I don't know. > > Anyway, now you can use > > (semantic-add-system-include > (DE-get-remote-variable "ROOTSYS" "server.example.com") > 'c++-mode) > After a couple of minor modifications that worked like a charm. I modified the call-process line to include my shell function, > (call-process "/usr/bin/ssh" nil t nil server "bash" "-i" "-c" "\"my_shell_func;env\"") and changed the DE-get-remote-variable call to concatenate /include as the $ROOTSYS variable returns the path to the system directory for the package not the include directories. So it ended up as, > (semantic-add-system-include > (concat (DE-get-remote-variable "ROOTSYS" "server.example.com") "/include") > 'c++-mode) > Regards, > David Can't thank you enough David! :) -- Suvayu Open source is the future. It sets us free. |
From: Suvayu A. <fat...@gm...> - 2009-09-09 20:11:47
|
David Engster wrote: > Suvayu Ali <fat...@gm...> writes: >> CMT uses various non-standard environment variables defined through >> shell functions in my .bashrc to look for other packages. I would like >> to add the path to a special package which is _not_ part of the >> framework. It is defined by a variable called $ROOTSYS, but only after I >> setup my environment using a shell function. Is it possible for CEDET to >> look at that since I am editing with tramp? > > I'm afraid I do not really understand your setup. But maybe we can > figure this out anyway. Where are these variables defined - on your > machine or on the remote one? They are defined in my .bashrc on the remote machine. The shell function sources some scripts in my work area on the remote machine to get these setup. > Adding a path from a local environment > variable to the system include path is straightforward: > > (semantic-add-system-include (getenv "ROOTSYS") 'c++-mode) > > Does that help in any way? > This also helps as I often have to use a local copy of that package for standalone projects. :) > -David -- Suvayu Open source is the future. It sets us free. |