Author Topic: Adding extensionless headers to a tagfile without * filespec?  (Read 6365 times)

Phil Barila

  • Senior Community Member
  • Posts: 742
  • Hero Points: 61
Adding extensionless headers to a tagfile without * filespec?
« on: November 02, 2006, 06:34:33 pm »
As discussed in this thread: http://community.slickedit.com/index.php?topic=540.msg2558#new HS2 and I determined that we could get the STL containers working again if we added the extensionless headers to our DDK/SDK tagfiles.  We both ended up using a * filespec to do it.
Is there a better way when adding a tree to a tagfile to pick up the usual files, plus extensionless headers?
Second, why does having the tag files without the STL headers in it mask the presence of those containers in the auto-tag files from the compiler?

hs2

  • Senior Community Member
  • Posts: 2747
  • Hero Points: 289
Re: Adding extensionless headers to a tagfile without * filespec?
« Reply #1 on: November 04, 2006, 10:40:17 am »
@Slickteam:
I think conc. managing compiler (auto-)tagfiles the std. ext.less files should be added (automatically) to the file list to tag w/o the need to explicitely specify '*' as file pattern b/c they are (std.) parts of the compiler env.
There should be no need for manual interaction except someone needs to setup something special.
And using '*' may accidentally include files (e.g. idl files) which I just dont want/need...

And ...
Quote
It would be great if someone could give a short explantion of the interworking of
compilers.xml / def_cpp_include_path_re / def_user_langext_files / tagging.

HS2

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3078
  • Hero Points: 449
Re: Adding extensionless headers to a tagfile without * filespec?
« Reply #2 on: November 06, 2006, 03:22:49 pm »
You can use the wildcard expression "*." (star-dot) to find all extensionless files.  This is better than * since it excludes *.idl, *.exe, and other extensions you don't want.  I believe that this works as a special case on Unix also, though it is slightly different than how the Unix shells would interpret *.

Quote
Second, why does having the tag files without the STL headers in it mask the presence of those containers in the auto-tag files from the compiler?

Use Tools > C++ Refactoring > Test Parsing Configuration... to verify that your "active" compiler configuration is what you think it is.  Also, if you have an extension specific C++ tag file named "cpp.vtg" (ucpp.vtg on Unix), it will be used ONLY if there is no C++ compiler tag file in play.  If you really want "cpp.vtg" to be used, name it something different, "cpp.vtg" is the name generated by the autotag dialog when you tag C++ runtimes, so presumably, if you have a compiler tag file in play, you already have your C++ runtimes covered.

Quote
It would be great if someone could give a short explanation of the interworking of
compilers.xml / def_cpp_include_path_re / def_user_langext_files / tagging.

  • compilers.xml is just how we store what you set up in Tools > C++ Refactoring > C/C++ Compiler Options...  We realized that this duplicated some of the functionality in auto-tag, so we consolidated it around the compiler options, which gives greater flexibility, since you can select a compiler configuration per project, and you can add new compiler configurations, and SlickEdit can automatically detect when these tag files are missing and generate them without needing the autotag dialog at all.  compilers.xml has no interaction with the def-vars.
  • def_cpp_include_path_re reflects what you configure for "Extensionless C++ File Path Regular Expression:" on Tools > Options > File Extension Setup..., "C", Options...  It's a regular expression for directories, used to filtering, not for searching.
  • def_user_langext_files reflects what you configure for "Extensionless C++ Files:" on Tools > Options > File Extension Setup..., "C", Options...  It has this weird "langext" name for historical reasons.  Visual Studio used to ship a file named "langext.dat" which has a list of the extensionless files that they shipped under their "include" directory. Presumably, they used that to set the correct file mode when those files where opened in their editor.

The two configuration options work together in an AND relationship.  If you open a file with no extension, we check that it's name matches one of the names in the list of extensionless header files names, and we check if the directory it is in matches the regular expression for directory names.  If it matches, then we consider the file as C++.  This prevents us from opening an executable that just happens to be named "allocator" as if it were C++.  It also prevents us from considering random extensionless files littered in your include directory as C++.

There is no relationship between the configuration options and the compiler configurations.  Also, we do not rebuild your tag files if you change the configuration options.  The options are aimed at the situation where you open an extensionless file, and we are trying to decide if we show it to you in fundamental mode or C++ mode.  However, the options do have the side-effect that when you build you compiler tag files, and we search for "*.", if the options are set right and the file is C++, then we tag it.

I'll be the first to admit that these are a pair of band-aids.  In ideal world, we would implement the Unix "file" utility within SlickEdit and use magic numbers and sampling to determine file types.  Of course, even if the schedule had room and the developer responsible for that aspect of the product made the changes, we might still need these bandaids on occasion to determine if an extensionless file was C++ or not.  The core problem was the gargantuan mistake made by the developers of the ANSI C++ standard when they ruled in favor of extensionless header files.

hs2

  • Senior Community Member
  • Posts: 2747
  • Hero Points: 289
Re: Adding extensionless headers to a tagfile without * filespec?
« Reply #3 on: November 07, 2006, 08:28:37 am »
Oh yes - this 'decision' was surely made by those theorists completely detached from the real world...
However, thanks for disclosing this details !
Did I get it right that I've to take care myself that ext.less headers are also included into the Compiler tag file ?

Maybe it's an idea to display a warning when attempting to tag a 'fundamental' file (ext.less header) not yet covered by the configuration. But this should be restricted to the Compiler tagfile. Workspaces may intentionally contain a lot of 'fundamental' files...

HS2

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3078
  • Hero Points: 449
Re: Adding extensionless headers to a tagfile without * filespec?
« Reply #4 on: November 07, 2006, 03:22:16 pm »
Quote
Did I get it right that I've to take care myself that ext.less headers are also included into the Compiler tag file?

Just checking the code now, when the compiler tag file is built, it also searches for all the extensionless files you have named in def_user_langext_files.  Provided the directory regex also matches, these files will be tagged when you rebuild the compiler tag file, if you rebuild it from scratch using Tools > Tag Files > "Rebuild Tag File".

Phil Barila

  • Senior Community Member
  • Posts: 742
  • Hero Points: 61
Re: Adding extensionless headers to a tagfile without * filespec?
« Reply #5 on: November 07, 2006, 07:19:51 pm »
OK, I think I understood about half of that.  As I write this, I think what it means is that if I add the "*." to the existing filespec for a new C tag file, I will get the same set of files that are automatically selected in the "C" Compiler Configuration Tag Files.
OK, let me test that.
...
OK, after finding all the different locations where the VS 2003 compiler tag file pulls headers from, I got approximatly the same results, although there are 5 extra files in the manually built one than the auto-generated one, I don't know how to get a text dump of the file names to figure out which ones are different, and I'm not going to switch back and forth between the tagfiles to figure it out.  Suffice it to say that adding *. to the existing filespec does indeed result in adding extensionless headers, so that's good news.  Still don't quite understand what is causing the suppression of the stl tags in the compiler tag file when the extensionless headers are not included in the PSDK/DDK tagfiles.  Oh wait, I wonder if it's related to the stl.h mentioned last week in another thread?
Checking...
Oh yes, that pesky stl.h header file.  With _STL_H_ defined before doing an "Add Tree" without the *. added to the filespec, the members of the stl containers pop right up.  And if I dereference the elements, the members pop just fine.  If I add the extensionless headers with "*.", then the element dereference doesn't work, but the members of the STL containers still appear.  Curiouser and Curiouser.    ???
Well, my config now is to add the files to the PSDK/DDK tag files without the extensionless headers, but with _STL_H_ defined, and now everything works.  I wonder why including the extensionless headers from the PSDK/DDK cause the element deref to fail?

hs2

  • Senior Community Member
  • Posts: 2747
  • Hero Points: 289
Re: Adding extensionless headers to a tagfile without * filespec?
« Reply #6 on: November 07, 2006, 07:48:04 pm »
@Dennis: Ok - that's what I wanted to know. I assume this applies to the built-in (std.) set of ext.less headers too.
... trying...
Great - it works w/o any filespec hacking !
I think I created the (DDK) tagfile before I realized to add 'inc' to the dir regex.

@Phil:
My DDK/KMDF config is (now) equivalent to your PSDK setup.
Summary (just for me):
Seems that I built the non-working tagfile w/o the proper dir regex related to the ext.less headers and w/o the magic bullet '#define _STL_H_'...
Now I did a complete re-build of all compiler files (to make the magic bullet hitting all sources) w/ the right dir regex.

HS2
« Last Edit: November 07, 2006, 08:02:26 pm by hs2 »