Hi Robert,
My experience is pretty limited, but the only way to fully customize source code import (as opposed to source code generation) in EA is to create your own grammar using the grammar framework.
There are some options you can set per language (Tools -- Options -- Source Code Engineering; Settings -- Preprocessor Macros), but they're limited. EA does not recognize cpp as a separate language, and it "handles" defined cpp macros by ignoring them.
Fundamentally, the issue is that C code with macros is not C code -- it's cpp code. If you feed the cpp code to the C compiler, it won't accept it either. The code has to go through the preprocessor to be turned into C.
The macros themselves can be used (are used) to essentially rewrite the C code at compile-time depending on the platform it's being compiled for, taking into account such things as endianism, address and word size, etc.
Thus, even if you create an EA grammar which can parse cpp code, you'll end up with a model of that cpp code, not a model of the C code. This is because the EA reverse-engineering process is in a sense single-pass: it creates a model from the source code. It does not parse the text, resolve macros, then creates a model from the resulting C code. That's just not how it works.
What you could do is create a cpp grammar and a cpp-to-C model transform. You would then end up with two models; one describing the cpp code and one describing the C code. That would be analogous to how the compilation process works.
However, cpp is a macro language and as such, UML is poorly suited to represent it. It can be done, but it won't be pretty. Recall that EA only attempts to create a structural model from the source code, not a behavioral one that would represent the sequences of statements inside the code blocks -- and what are the structural concepts of a macro language?
The alternative is to run the cpp code through the preprocessor, resulting in macro-free C code which you can then reverse-engineer into EA.
HTH,
/Uffe
