How to tweak Eclipse's C++ Indexer?

Question

I'm using Eclipse as my IDE for a C++ project, and I would love for it to tell me where a given symbol is defined and what the parameters are for a function.

However, there's a catch: I also use Lazy C++, a tool that takes a single source file and generates the .h and the .cpp files. Those .lzz files look like headers, but this tool supports some very mild syntactic benefits, like combining nested namespaces into a qualified name. Additionally, it has some special tags to tell the tool specifically where to put what (in header or in source file).

So my typical SourceFile.lzz looks like this:

$hdr
#include <iosfwd>
#include "ProjectA/BaseClass.h"
$end

$src
#include <iostream>
#include "ProjectB/OtherClass.h"
$end

// Forward declarations
namespace BigScope::ProjectB
{
  class OtherClass;
}

namespace BigScope::ProjectA
{
  class MyClass : public ProjectA::BaseClass
  {
    void SomeMethod(const ProjectB::OtherClass& Foo) { }
  }
}

As you see, it's still recognizable C++, but with a few extras.

For some reason, CDT's indexer does not seem to want to index anything, and I don't know what's wrong. In the Indexer View, it shows me an empty tree, but tells me that it has some 15000 symbols and more stuff, none of which I can seem to access.

So here's my question: how can I make the Indexer output some more information about what it's doing and why it fails when it does so, and can I tweak it more than with just the GUI-accessible options?

Thanks,

Carl

Answer 1

I'd imagine its one of:

• Eclipse doesn't want to display non-C++ resources in the tree (I've had problems with this)

• You don't have "Preferences > C/C++ > Indexer > Index All Files" enabled.

• You want to use the "Full C/C++ Indexer" rather than the "Fast C/C++ Indexer"

Answer 2

The CDT parser/indexer won't recognize weird extensions like that. The only thing you can do is to define macros on the Paths and Symbols property page to trick the parser. Try creating macros for $hdr, $end and $src that have empty bodies. That way the preprocessor will remove them and the parser won't choke on them.