Tag GNU Compiler Libraries: Search Path for C/C++ Preprocessing Header Files

[mjdl]

I've generated a vsparser header file for a flavour of the Gnu C/C++ compiler (MSYS2, mingw-w64-x86_64 on Windows 7 x64 to be exact) using Bourne shell commands

Code: [Select]

echo ""|cpp -x c -dM - >mingw-w64-x86_64_c.h and

Code: [Select]

echo ""|cpp -x c++ -dM - >mingw-w64-x86_64_cpp.h for the C and C++ sets of predefined macros. I then use those custom header files in the C/C++ compiler configurations for the auto-tagging of compiler libraries.

I get the compiler's default header include paths by executing e.g.

Code: [Select]

echo ""|g++ -x c++ -v and looking for the section beginning "#include <...> search starts here:"

But the Slickedit tagging logic has to pick up at least two other header files in the Slickedit installation, C:\Program Files\SlickEdit Pro 20.0.1\plugins\com_slickedit.base\sysconfig\vsparser\g++-common.h and C:\Program Files\SlickEdit Pro 20.0.1\plugins\com_slickedit.base\sysconfig\tagging\preprocessing\usyscpp.h. The first #include "g++-common.h" is at the bottom of my own generated vsparser header file, and the latter appears to be implicitly included.

So, am I on the right track here? What is the real include search path for the tagging logic's own header files once I specify my own vsparser header file in the compiler configuration? (And is the g++-common.h file generic enough for a Windows flavour of the Gnu compilers? Trying to read it gives me a headache...)

[Dennis]

The vsparser header file is for the C/C++ Refactoring engine.  It doesn't sound like you are trying to get that going, so you can effectively ignore that.

The only thing you really need to bother with is the include path.  Here is a simple for gcc 4.6.3 on Unix (compilers.xml).

If your MSYS compiler is on your path, auto tag should have found it without you having to do extra work.  Tools > Tag Files > AutoTag...

You may need to hit Add Compiler... if you just added that to your path before restarting SlickEdit.

Code: [Select]

<C_Configuration
Name="GCC-4.6.3-x86_64-apple-darwin12.0.0"
Header="sysconfig/vsparser/g++-macos.h">
<Includes>
<Include Dir="/usr/gcc4.6.3/include/c++/4.6.3/"/>
<Include Dir="/usr/gcc4.6.3/include/c++/4.6.3/x86_64-apple-darwin12.0.0/"/>
<Include Dir="/usr/gcc4.6.3/lib/gcc/x86_64-apple-darwin12.0.0/4.6.3/include/"/>
<Include Dir="/usr/include/"/>
</Includes>
</C_Configuration>


[mjdl]

Sorry, just noticed your reply!

I'd somehow got the impression that the vsparser header file (generated as I showed in my original post) was vital for communicating the particular compiler's predefined macros (which depend on the language, e.g. C or C++, and version chosen, e.g. echo ""|cpp -x c++ -std=c++11 -dM > MINGW64-c++11.h) to the Slickedit header parsing engine--since, as you say, as long as the MSYS2 executable directories are on Slickedit's path, the compiler header directories will be found automatically by the compiler configuration logic (and may be changed to suit particular project requirements).

So where I need to go is to the global C/C++ Preprocessing Options panel and use the Import... file chooser to import the header file I generated using the cpp -dM command shown in my original post, right? (It would be more logical to have user defined C/C++ compiler header processing in the per compiler configuration rather than globally for all Slickedit C/C++ processing.)

Nevertheless, will changing the "Header File (optional)" in the Compiler Configuration to a header file not located in the relevant Slickedit installation directory cause problems with the header parsing, e.g. processing the added "#include g++-common.h" directive at the end of the custom vsparser file I generated? (I copied that extra file into the directory where my custom header file was located, just to be sure.)

 Should I change it back to the default installed g++-win.h vsparser header file, even if that file contains definitions inconsistent with my custom generated file?

I tried to follow the logic in the relevant Slickedit system macro files to find how the #include "..." directive might be processed, but my mind blue-screened after a while... I simply want to take advantage of all the Slickedit preprocessing with the greatest possible accuracy...

[Dennis]

You have a good point about fine-tuning the tagging based on the compiler settings.  The difficulty with that is that the compiler setting is a per-project and per-configuration setting, and the workspace tag file is workspace level.

You should also know that the standard preprocessing configuration files (syscpp.h on Windows and usyscpp.h on Unix) shipped with SlickEdit include many of the Windows/VC++ and Linux/g++ builtin defines, so the additional tuning you would get would be somewhat minimal.

That said, I am going to file a feature request to factor the preprocessing configuration file into the C/C++ preprocessing configuration, but I do think it needs more consideration because the setting is configuration specific.

For your projects, I would suggest appending the compiler defines to your workspace preprocessing configuration header, that is:

Code: [Select]

  echo "" | cpp -dM >>[workspaceName]-cpp.h

[mjdl]

I have to admit I've managed somehow to get things completely confused and up the garden path the files in plugins\com_slickedit.base\sysconfig\tagging\preprocessing are the ones relevant for the default preprocessing, not the files in plugins\com_slickedit.base\sysconfig\vsparser ...and this is even mentioned in the help under configuration files!

And re. fine-tuning pre-processing per compiler settings, maybe this is not such a great idea, given that compiler tagging information is kept in separate files which would multiply complexity with the number of compiler configurations (the perfect might be the enemy of the good-enough here).

Thanks for all the help & consideration.