CEDET

Suvayu Ali <fatkasuvayu+linux@...> writes:
> Earlier used to parsing of my header files by putting something like 
> this in my .emacs
>
>> (setq athena "/ssh:suvayu@...")
>> (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

Hi David,

Firstly, thank you for the detailed reply.

David Engster wrote:
> Suvayu Ali <fatkasuvayu+linux@...> writes:
>> Earlier used to parsing of my header files by putting something like 
>> this in my .emacs
>>
>>> (setq athena "/ssh:suvayu@...")
>>> (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.

Suvayu Ali <fatkasuvayu+linux@...> 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

David Engster wrote:
> Suvayu Ali <fatkasuvayu+linux@...> 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.

Suvayu Ali <fatkasuvayu+linux@...> 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@..." or put a
proper server definition into .ssh/config.

Regards,
David

Hi David,

David Engster wrote:
> Suvayu Ali <fatkasuvayu+linux@...> 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.