C/C++ Preprocessing per project?

[skywise]

In the code base I'm currently developing under there's a macro for a string declaration type along the lines of:
#ifndef TYPE_I
#define TYPE_D(name,value) extern const mylibstring name(value);
#endif

SE didn't parse this so anywhere I saw "name" used it would appear as an error in the color syntax parser.  I finally got frustrated enough (going through a large table of these values) that I got off my lazy butt to add it to the preprocessor via Tools | Options | Languages | Application Languages | C/C++ | C/C++ Preprocessing.  (Ahh, much better).

My question-
This appears to be an editor-wide setting, not a project setting.  Is there a way to specify this in the project's options?  This macro is only used in this project and I'd hate to have it "pollute" all my workspaces, let alone what I do if I run into a similarly named macro with a wholly different definition in another project.
(Bonus question!) SE did recognize the macro definition (auto-completing it as I typed it into the New Define form), so it was properly tagged.  I assume this was still omitted from Context Tagging(r) because of the performance concerns?  I can sort of understand that but it seems odd that SE recognizes it, parsed it, but won't actually do it unless I manually enter the exact definition into the table which SE already recognizes.  Perhaps (if there's no per project preprocessor tagging) there could be a per project form that lists the macros/defines not preprocessed and the ones we want to be forcibly processed could be moved onto the forced list?  (Sort of like the associated file types form?)

[Dennis]

There is a feature which is not exposed by the GUI which will help you.

Suppose your workspace is named MediaCenter.vpw.  If you create a file in that same directory named "MediaCenter_cpp.h" and stuff your #define's in there, they will automatically be added to the preprocessing for that workspace.  Yes, this is per-workspace rather than per-project, but it can be very helpful.

We can't just blindly expand #define's when doing tagging for many reasons. 
  1) it would be incredibly expensive and performance limiting to recursively parse #includes to find #defines
  2) not all #defines are good to expand.  Constants and function-like statement macros are better off not being expanded.
  3) We can scrape #defines from the tag file, but only after the tag file has been built.  Sort of a chicken and the egg problem there.

You do have a good idea to have a GUI for scraping #defines from the user's workspace and adding them to the preprocessing table.  It has been on our to-do list for years, but we have a big to-do list.

[chrisant]

Excellent, thanks for sharing the WorkspaceName_cpp.h feature, Dennis!
Is it new to v17?

[hs2]

I guess this highly appreciated solution of a long standing request was added recently and it's still kinda beta. At least it's not officially documented and might need some more tuning (?).
Nethertheless - thank's lot Dennis for this very helpful improvement HP++
HS2

[skywise]

Yeah, thanks for that - That's ALOT faster!
(Although I had some weird funkiness with tagging/syntax coloring at first...  Are there issues if you leave the file open while letting retagging occur automatically?  Right after this I had several instances of the syntax coloring stopping altogether, or some of the new tagged variables getting colored correctly while others would cross reference properly but coloring would be "no symbol".  I then shut down and restarted and the macros weren't colored at all... After playing with it for a few minutes and encountering various states of functionality while trying to Rebuild Tag file or retag all source files in the background with no luck, the following steps seemed to clean it up - Make sure the workspace_cpp.h file was closed, Tools | Tag Options | select workspace and then rebuild tag file, unchecking "rebuild modified files" and "background tagging".  Afterwards everything worked as expected.

[davehohl]

Is it still the case that preprocessor files can only be configured on a workspace-wide basis? It sure would be nice to be able to do it on a project-by-project basis!