Project include directories

[dunkers]

What's the trick to getting this to work? Sometimes it works for me but right now I'm setting up a new project and it doesn't work for me. I can't remember all the twists and turns and dead ends I tried last time I forced it to succumb, and I'm sure there must be a simple solution...

Imagine a project layout thus:

C:\...\project  <--- project directory. Source is here.
C:\...\project\lib  <--- some kind of library code
C:\...\project\lib\include  <--- include dir for lib code
C:\...\slick  <--- SE workspace files

In the SE project properties, directories dialog the settings are:

Working directory: ..\
Includes: .\lib\include\

The problem is, if I drop the cursor on a lib function the preview window is blank. It should should the details from the lib include file.

I've tried absolute paths, "..\lib\include", "..\lib\", "lib\" and various combinations. Nothing works, yet the exact same code and layout for a similar project does work.

In both projects, the compiler includes work as expected. Perhaps significantly, these include directories are absolute paths and set when the project is created.

Incidentally, the compiler include path has a right pointing triangle at the start. If I click that it changes to a filled-in triangle point down to the right. Apart from that, I can't detect any other effect. What is is meant to do?

Also, the help says that using the up and down arrows I can move my include paths above or below the compiler paths, but those similarly have no effect regardless as to which path has focus.

[chrisant]

Part of it sounds like here.  V17 started showing the compiler includes in the project includes list.  Not sure if it was an intentional change or not.

I'd probably compare closely the all the directory settings in the two .vpj files, and also compare the compiler definitions between the two projects.  And maybe the current working directory.

[dunkers]

I had that delete problem too, resolved by editing the entry to an empty string. That's OK for one or two, but I wouldn't want to have a big list

I've resolved my immediate issue by creating an auto tagfile for the sub-lib. But having done that I fail to see what the point of sticking the lib path in the directories dialog is. Perhaps my expectations are somewhat adrift from what it is designed to do.

[chrisant]

Do you mean you expected the Includes directories in the Directories tab of the project dialog would show up in the tag file?

Only files that are added to the project show up in the tag file (in the Files tab of the project dialog).

According to the help text, here's how the Includes directories are used by SE:

Includes - Specifies the directories the cursor_error (Alt+1) and next_error (Ctrl+Shift+Down) commands will search when trying to open a file. For COBOL and High Level Assembler, this list of directories is used to find copy books or macros. You might want to add some of your own include directories here before the compiler's include directories. You can specify environment variables with the syntax %(EnvVarName) (see Environment Variables). Click the button to the right of this field to browse for an include directory to specify. Use the up and down arrows to move the includes up or down in the list.

[dunkers]

No exactly. I expected the stuff in the include files to show up without explicitly creating a tag file, I guess. Having now had some time to ponder this I'm not exactly sure, to be honest!

Mmm. So, why would I put something there? I saw the help entry on errors, but surely an error is going to be in my code. I realise that an error in my code might manifest itself as an error in an include file, but showing the include file in that case isn't awfully helpful IMO - I'd much rather know which file included it.

[chrisant]

I saw the help entry on errors, but surely an error is going to be in my code. I realise that an error in my code might manifest itself as an error in an include file, but showing the include file in that case isn't awfully helpful IMO - I'd much rather know which file included it.

I don't know, maybe you don't need to put anything there.

A couple reasons off the top of my head that I put things there:
- Files aren't always part of the workspace; especially in large code bases.
- Compilers can report errors that refer to where a base class/template was defined ("Y derives from X which doesn't have Foo method to override; see definition of X in file c:\external\library\X.h").

Also the excerpted help text gave additional examples why COBOL and High Level Assembler can benefit from specifying include directories.

Probably depending on how you use SE and which features you utilize, you may or may not have an interest in setting them.  It might be reasonable to leave them blank until a situation arises where SE can't find a file.

[dunkers]

Those are decent reasons but, as you say, perhaps I don't need to be mucking about in there really. Thanks for your help on this

[Dennis]

Adding a directory to the project includes does not automatically pull the files under that directory into the project (and hence the workspace tag file).  It is just used for errors and include file path searching (when you put your cursor on a #include line and hit Ctrl+Dot).

To make sure the files are also included in the project, you should add them on the Files tab of the project properties dialog.  From that dialog, you can see what files and wildcards are already added.  It is also useful to go to Tools > Tag Files... and look at the actual list of files that are tagged.

Include files are about the most essential thing to have tagged, since they include important things like defines, typedefs, class definitions, etc.  Tagging can basically be crippled if those definitions are not available.

[dunkers]

Thanks for the clarification, Dennis. My issue was that the lib files aren't part of the project per se and I only wanted access for the purposes of parameter lookups and similar, just like the compiler library does. I'm now aware that a separate tag file is the way to go!

Actually, mentioning that, it would useful if a project specific tag file could be achieved in one hit instead of the indirect way we currently have to do it (that is, create a language tag file, delete it from the list of tag files without deleting it from the disk, then add it to the auto-updated section).

[Dennis]

Try creating a workspace for the lib files.  Then switch back to your main workspace and add that the tag file associated with the lib workspace as an auto-updated tag file.  This is how the system was intended to be used, and has the added benefit that you can use the 'vsmktags" tool to rebuild the auto-updated tag file.

[dunkers]

I'll give that a whirl. Thanks for the suggestion