Best Practices for Tagging runtime libraries

[jbhurst]

Hi,

I have several different independent projects.  In each of them, I would like to set up tagging for the runtime libraries.  In the case of Java, these are JAR files, although they could also be source trees or .java files.  In the case of C/C++, they would be .h files.  In the case of .NET, they would be DLLs.

I can see two straightforward ways of doing this:

1) Use the Extension-Specific Tag Files.  These are easy to set up and manage with the Context Tagging - Tag Files dialog.  However, they are not useful in most cases, since they don't permit different versions of the runtime libraries per workspace. In fact, this limitation affects auto tagged standard libraries in many cases, if you have multiple versions of the standard library. For example, I have JDK1.5 and JDK1.6 on my machine.  I can't define them both at the same time.  When I used to do C/C++ work, I had the Microsoft VC++ compiler and the GNU compiler both installed -- the same problem occurs.

2) Add all the files to the workspace tag file.  This seems to work for me with JAR files.  Scott W told me this was not the best way to do it however; I can't remember the exact reasons why. 
   
There is also the suggestion to use Auto-Updated tag files at
  http://community.slickedit.com/index.php?topic=564.0

I couldn't get this to work.  I followed these steps:
  1. Open my Java project.  No JARs are tagged, either in "Java" Tag Files or in the workspace tag file.  The Auto-Updated Tag Files item is empty.
  2. Open the Context Tagging Tag File dialog.
  3. Click Add Tag File.
  4. Select Java.
  5. Specify libs.vtg in my project directory for the Tags Database.
  6. Specify lib/*.jar, recursive in the Add Tree dialog.  SlickEdit builds the tag file.  The tag file appears in "Java" Tag Files and contains all the JARs in my project.
  7. Select Auto-Updated Tag Files in the tree.
  8. Click Add Tag File.
  9. Specify my libs.vtg as the Tags Database to add.  The tag file now appears in the Auto-Updated category and the "Java" Tag Files category.
  10. Select the file in the "Java" Tag Files category.
  11. Click Remove Tag File.
  12. Click Yes for removing the file from the tag file list.
  13. Click No for permanently deleting the file.  The tag file now appears only in the Auto-Updated category.
  14. Click Done.

After following these steps, I closed the project and examined the workspace definition.  It contains this entry:

  <TagFiles>
    <TagFile File="libs-2.vtg" AutoUpdateFrom="libs.vtg" />
  </TagFiles>

The two files are in the directory, and have the same name. I assume the two files reflect the intended network usage of this feature.

However, none of the Context Tagging features are working for symbols defined in the JARs.

If I tag the JARs in "Java" Tag Files, or in the workspace, the features work.

So I have these questions:

1) Should this procedure with Auto-Updated tag files work?

2) What is the downside of tagging the JARs in the workspace tag file?

Does anyone have any further comments about best practices for tagging runtime libraries?

[hs2]

Hello John,

2) Add all the files to the workspace tag file.

This could slow down your workspace tagfile update. SE would consider much more files (which also won't change).
And it would also render 'open file from workspace' (Files TB) unusable.

I was also a bit astonished about the copied tag file and I'm curious about the reason...

HS2

[jbhurst]

OK, hs2.  Of course you are quite right (as usual). I had thought I could add files to the workspace tag file but not to the "project". It didn't work like that ... adding them to the tag file did add them to the project, so the problems you mentioned occur. And this must be why Scott recommended against it.

Actually this works pretty well anyway for Java JAR files. There are typically not a great number of JAR files in a project, and their names are quite different from other typical names of files in a project, so open files from workspace works fine. I believe the workspace tag file update could be impacted though. In my case I didn't notice too much degradation. Ideally I would prefer to tag .java source files for open source libraries, rather than compiled JAR files, and this approach wouldn't work (well) for that.

So, I wonder what went wrong when I tried to apply your technique? Do you see anything wrong with my steps?

BTW, when I said "have the same name" in my post I meant "have the same size".

Regards

John Hurst
Wellington, New Zealand

[hs2]

@John: Everything seems perfectly right and it should work ...
As posted I'm using a quite similar config except it's a C/C++ project.

Sorry, no idea. Hopefully the SlickTeam can solve/clarify it before 12.0.1 goes 'gold'

BTW: I think they make a (sync'd) copy of the workspace related auto-updated tagfile to avoid concurrent accesses to it e.g. when the real AU tagfile gets re-built (async) by a cron job or whatever.

HS2

[jbhurst]

@hs2:

I tried your method with Java source files rather than JAR files, and it works! I think this is the best way to do tagging for open-source libraries with the source code. With just the JARs, I guess adding them to the workspace is maybe OK.

I can see how it would work fine for C/C++ too. I suppose with .NET it's the same as for Java ...

Thanks again, you are indispensable.

Regards

John Hurst
Wellington, New Zealand