Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Help request to resolve a CDT bug related to macro handling

Hi Tibor,
What you are describing sounds like a bug, yes. Unfortunately, as you pointed out, the current code in CDT in this area is difficult to grok, and hard to maintain even for experts. This is one of the reasons for bug 290631, new scanner discovery. That functionality is intended to cover/reimplement that of provided by Includes and Symbols tabs, hopefully with more ISV or developer-friendly code. I am sure that the problem that you are describing is non-existent there. I suspect the current Paths&Symbols as you know them might become irrelevant even if they still will be available in the new SD.

Andrew

On Mon, Jan 16, 2012 at 7:06 AM, Békési Tibor <tibor.bekesi@xxxxxxxxx> wrote:
Hi,

So the main issue is that you cannot define the same macro name with
different values for resources (file/folder) on the same path level.
It seems, that the first registered value become the "strongest one".
If you look into .cproject file in the project root,
which is basically the serialized XML version of the CDT object model,
you can find the right values there.
The UI is inconsistent with the model. Unfortunately, the indexer also
seems to use these inconsistent settings -> the editor is directly
affected for example.

Why is this an issue for us? Because what you see in the source code
editor, is not what you'll get in the compiled binary.

If you create a small project with such settings (using the internal
builder), you can see, that the right macros are used for compilation.
This is the primary example of what you see in the editor, is not what
you get in the code.

On the Java side, this dual behaviour becomes clearly visible:
  - When you open properties on a resource (in this case directory) in
the UI, an ICResourceDescription implementer class
(CFolderDescription) is used as a source to update the content of the
JFace properties dialog.
  - Inside the UI update code, the getLanguageSettings() method is
called to get detailed information, required to fill the macro
settings tab, for example amongst other things. I saw 2 different
scenario here:
    - CFolderDescriptionCache array is returned (contains invalid macro info)
    - BuildFolderData array is returned (contains valid macro info)
      (further accessed by casting to CFolderData)

If you opened C/C++ General / Paths and Symbols first, the first
scenario occurs. But if you browse into C/C++ Build, from that point
on, you'll get the second scenario.
For files, the according class names are CFileDescription ->
CFileDescriptionCache / BuildFileData.

The internal model code was mostly written by Intel Corporation, but
unfortunately I do not find any JavaDoc in the sources.
Additionally most of the classes are using cache/proxy classes to
speed up access, so it's pretty hard to track what is exactly
happening in the background. :-(

Your opinion/comments are welcomed!

Best regards,
Tibor
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top