Re: [cdt-dev] Help request to resolve a CDT bug related to macro handlin

[Békési Tibor <tibor.bekesi@xxxxxxxxx>]

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