References to standard include files

[jbyrne]

Hi,

I'm currently evaluating SlickEdit, and trying to get to grips with it. One thing I've not been able to work out is how to get references to standard C include files to work properly.

I'm using SlickEdit on Linux for a cross-compiled project, so I am not using the standard GCC. I added my cross-compiler GCC to the list of C compilers, and set the correct path in "Built-in Compiler Include Directories". I created a project and chose this compiler as my compiler.

The problem I am having is that if I open one of the C files in my project and press Ctrl+. on a line such as "#include <stbdlib.h>" the editor opens "/usr/include/stdlib.h" instead of the correct one "/opt/gcc-3.4.5/arm-linux/arm-linux/include/stdlib.h". I can't work out why it's doing this. I've looked through various settings pages, and "/usr/include" isn't specified anywhere. If I look at "Tools->Tag Files..." I can see that the correct include files are listed under "C Compiler Configuration Tag Files", and nothing else is.

What am I doing wrong?

James

[Graeme]

In project properties, on the directories tab, have you entered the path to the include files for your cross compiler?

I don't know what the search order is for include files but it looks like it includes usr/include in Linux automatically.

Graeme

[jbyrne]

Thanks Graeme, that solved the problem. I had assumed that the path specified for the compiler's include files would automatically be checked (otherwise, what is the point of specifying it?) but it appears not.

It would be nice if the manual was a little clearer on search paths and the relationship between these include paths and the tag files. The online help for the project include paths says it "specifies the directories the cursor_error and next_error commands will search when trying to open a file", but it seems it also applies to looking up references. Or is it that the way the editor looks for files in #include directives is different from the way it looks for symbols?

James

[Graeme]

Well, I love Slickedit but I'm not a fan of its help information -  it has a few too many holes in it for my liking.  For example, the information on the compiler properties dialog (where you said you entered the include paths) is part of the "refactoring section"  - I would expect this to be part of the "project and workspaces" section, or at least referenced from the project properties section.

I guess you've struck an undocumented feature regarding what happens with Ctrl+. on a #include line - it definitely behaves differently than lookup on a symbol.  Lookup for symbols uses the tag files but it seems the #include lookup does not.  I'm unsure whether it's illogical for the #include lookup to ignore the include directories belonging to the "active compiler"  - I suspect it is illogical because if you switch compilers, you most likely switch include files as well.  Slickedit doesn't seem to provide for this within a single project because the include paths on the directories tab aren't tied to the selected compiler.  It would make more sense if the include files entered on the directories tab didn't have to include compiler include files and were just for project specific include folders so this might even be an outright bug.

Slickedit has many more positives than negatives though.

Graeme

[pearish]

I'm experiencing a similar issue with includes. When I move the cursor to an include of the form: #include "foo.h" and press Ctrl '.', I get a dialog requesting the directory of the include file. However, if I move the cursor in the C file to one of the types defined in foo.h and press Ctrl '.', SlickEdit opens the correct file and places highlights the type, as expected. So why can't SlickEdit locate the include file, when it can certainly locate types in the include file?
~jeff

[hs2]

As Graeme described #includes seem to be handled a bit different.
I don't know the reason for that. Maybe one of the Slickteam could give an explanation.
However, you have to add the paths to #include's which are not already part of your workspace (or maybe project ?) to your Project Properies -> Directories.
It's quite similar to the INCLUDE path for your compiler or VPATH for make.

HS2

[pearish]

It appears that one difference from the include path of the compiler, is that you have to explicitly specify each and every possible include directory. You can't for instance, specify "/usr/local/foo" and have it find includes that are in "/usr/local/foo/bar". Or am I wrong? (I hope)
~jeff

[hs2]

I afraid you are right...

HS2

[Dennis]

The standard way for a C++ compiler (preprocessor really) is to not search include directories recursively for include files.  I am aware that Borland's C++ compiler violated this standard by adding recursive include directories, but most other compilers stick to the standard, which helps keep code portable.  Of course, you can always give a relative path (like <sys/stat.h>) when doing a #include.

As for the relationship with C/C++ compiler includes, the quick answer is that there wasn't any, this was an oversight.  I will have support make a hot fix available for this issue tomorrow.

Once you have the fix, when you do cursor-error (or Ctrl+Dot) on a #include, SlickEdit will look first in the user level include paths configured in your project include directories.  If it doesn't find it there, then it will look in your active C/C++ compiler include directories.  Next stop on Unix, as a last ditch, is to try /usr/include.  If it doesn't find it there, it will search your workspace for a matching file.  There is actually more complexity to it than that, but the bit about checking the compiler includes is the key thing.

You might be wondering:  when do I add an include path to the project, and when do I add it to my compiler includes?  The line is clear.  The compiler include paths are intended to be the include search paths that are BUILT IN to your C/C++ compiler's preprocessor.  These are the paths that you typically do not pass to your compiler with -I.  Any path that you have to pass to your compiler in order to build belongs in the project include paths.

[hs2]

Thanks a lot Dennis ! Sounds logically and it's good to stick to std. behaviour.
Now it's (more) transparent what's going on ... at least this little part of Ctrl-Dotting

HS2

BTW: Would be nice if someone could also cross-check this before uploading the brand new hotfix pack.
http://community.slickedit.com/index.php?topic=598.msg2739#msg2739

[Graeme]

Thanks for the information Dennis.

What do you mean by "searches recursively"  - do you mean searches subfolders and their subfolders etc as asked for by Jeff?  I don't think Borland does this as far as I know.  This would be a bad thing to do.

The C/C++ standards don't specify anything at all about how #include searches are done - just that "" and <> are both implementation defined.  I think Slickedit has a tough job to try and follow the same search as a given compiler.  With compilers  I know of, the difference between <> and "" in the #include is that when <> are used, the search starts with the -I and leaves out folders containing the file doing the #include and the "current directory".

I think Visual C++ does something slightly different to some other compilers in that as well as searching the folder containing the file doing the #include, it searches "grandparent" folders - i.e. if a file in folder A #includes a file in folder B which does a #include, then folder A is a grandparent or something.  In the case of Visual C++, the compiler also uses the INCLUDE environment variable, after searching the /I folders. 

I wonder what the consequences are of specifiying include folders for a compiler that aren't actually built-in.  For C++Builder, slickedit default config has the CBuilder/include folder entered as a "built-in" path but I don't think it is built in - you have to supply it in a -I either on the command line or in a config file.

As far as I can see, the lookup on the #include should find the right file if the search order that slick uses is documented and all people have to do is enter in a full set of paths in their project includes, in the order that matches what their compiler will do  (except for the "grandparent" problem of VC).

Anyway, hopefully the doc team will read this thread and update the (now online) help regarding what the project includes and the compiler includes are used for  - and how they affect tagging. 

Graeme

[hs2]

AFAIK the '<>' #include-s refer to 'standard' includes.
This means that the compiler built-in search path and the INCLUDE path is considered.
INCLUDE may be explicitely set using the env. var itself or by adding the -I or /I switch to the compiler cmdline.
'""' #include-s are searched in the cwd and you can omit that notation by adding '.' to the INCLUDE path.

HS2

[Graeme]

AFAIK the '<>' #include-s refer to 'standard' includes.
This means that the compiler built-in search path and the INCLUDE path is considered.
INCLUDE may be explicitely set using the env. var itself or by adding the -I or /I switch to the compiler cmdline.
'""' #include-s are searched in the cwd and you can omit that notation by adding '.' to the INCLUDE path.

HS2

As far as the C++ standard is concerned there's no such thing as a "standard include" or a "built-in search path" and not all compilers have them.  What a specific compiler does is specified by its documentation.  When "" is used, I suspect all C/C++ compilers first search the folder containing the file doing the #include if the #include specifies an incomplete path and what they do after that varies.  'INCLUDE' is a VC specific environment variable.  Borland and VC search up the chain of #including files - on Unix, it seems GCC does not (or doesn't document it).

http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html#Search-Path

The above web page also describes what GCC does differently between "" and <>  - it is very GCC specific.  With the Borland compiler, <> means only -I directories are looked in.

Graeme

[hs2]

Thanks for this further information Graeme.
I think it's common to many compilers that they use some env. vars. But of course a specific set...
http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
And I think that e.g. gcc has a built-in default search path ...
BTW 'standard' was quoted b/c

...there's no such thing as a "standard include"...

However, it's interesting but I afraid it's going OT ...

HS2

[Graeme]

BTW 'standard' was quoted b/c

...there's no such thing as a "standard include"...

HS2

Um, well, what I actually said was

As far as the C++ standard is concerned there's no such thing as a "standard include"

and this was *after* whatever you said, so the meaning of your comment here completely escapes me.

Graeme