Indexer takes wrong locations for C++ headers
Indexer takes wrong locations for C++ headers
- Subject: Indexer takes wrong locations for C++ headers
- From: Andreas Grosam <email@hidden>
- Date: Sun, 21 Mar 2004 15:49:16 +0100
Hi All,
I posted this issue a couple of weeks ago, without any reply -- seems,
there is nobody *attempting* to compile C++ projects ...
Although there are several other problems related to C++ projects
(templates, debugging, etc.) I want to restrict myself to complain
about the indexer:
In short: the indexer does not locate C++ headers using the correct
path.
In order to quickly recognize what I mean, please, create a C++ console
project ("C++ Too"l). Ensure the indexer is enabled.
Open the main.cpp file. (You may notice, that - even indexing is
enabled - the rightmost "#" popup button in the header of the source
view pane is disabled. This popup shows you the current included
headers for that file. This button shall be enabled, but for some other
reason it is not - but this is yet another issue. So, enforce
re-indexing - and it will be enabled afterward, showing the included
headers.)
In the main.cpp file there is one C++ standard header iostream
(directly) included. The popup shows one (directly) included header. (I
would like to see ALL headers - but this is a personal preference).
More important is, that the header file shown is NOT the header file
which will be included by the compiler!!
When opening this header <iostream> - for instance by using that "#"
popup - it will open the header located in
/user/include/gcc/darwin/3.1/g++-v3/.
That is, the indexer has been indexed files from the 3.1 version of the
header files, which is wrong in this case, as the compiler uses the
*current* system headers which are located in the /3.3/ path.
When you take a closer look at the other symbols so far indexed, you
can examine that ALL symbols from C++ headers will be located from the
path /user/include/gcc/darwin/3.1/.. - and even regardless of how you
setup your project/target which may have an affect on the location of
the C++ headers.
Another problem with the current indexer is, that it is unable to take
the *project and target settings* into account. Suppose, there is a
macro defined in a conditional:
#ifdef DEBUG
# define MY_MACRO xxx
#else
# define MY_MACRO
#endif
So, when I cmd click at MY_MACRO somewhere in my source code, I
definitely want to be routed to the propper place where it is
*actually* defined. Of course, this depends on the definition of DEBUG,
which in turn may depend on the current project/target settings and a
possible definition within some file of the "translation unit".
It looks like, the indexer is not aware of macro definitions set in the
command line - or when they are defined in the project or target panel
as a Preprocessor macro. (Or when they are defined in a precompiled
header??)
When you define DEBUG as one argument in the "Preprocessor Macros"
property in the project or target panel, it will NOT be taken into
account by the indexer!
So, as a rule of thumb - in order to avoid indexer confusion, don't
specify macros in the target/project panels.
The next thing is, the present capablities of browsing and showing
information is very restricted. It would be a great help, if browsing
really supports understanding of complex projects. (Please take a look
at the class browser in CW, so you see quickly what I mean).
Yes -- what I actually want to say is: I really would appreciate it if
there were a totally new approach:
Useing the current compiler, preprocesser and build system and add a
new feature to the tool set which generates a structured symbol
database.The meta data of the symbols (classes, typedefs, macros,
functions, comments, ect.) need to be defined in a language independent
manner and in an easy to use format - e.g XML (but XML might have
performance issues when it is used for code sense).
In the open source, there are already similar solutions (doxygen). But
there are a couple of common aspects, generating code and generating
browser symbols - for instance, precompiled headers or the dependency
chain, so that it is obvious to gain advantage when using the compiler
and the build system itself, rather than using an external tool.
Thanks to all developing XCode
Andreas Grosam
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.