[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Can't make sense of the PerProjectSICollector behaviour
|
Hi Eugene,
For build output parsers, different files can contribute different macros. If the collector cleans all settings on any build, recompilation of any single file would cause settings contributed by other files to be lost (as we are talking per-project collector). That is not to excuse any problems it may cause but it may explain why it was done this way.
Andrew
On Tue, Dec 13, 2011 at 6:17 PM, Eugene Ostroukhov
<eostroukhov@xxxxxxxxx> wrote:
I am trying to discover scanner info from our cusom compiler. Our compiler has a command-line switch that specifies specific hardware architecture to compile for. There are macros that depend on this switch - hence I am trying to recompute their values when compiler setting is altered.
The problem I'm facing is that PerProjectSICollector::definedSymbolsNeedUpdate merges discovered macros with the previous macro values. This results in SymbolEntrys that have several "active" values.
The obvious solution I see is to write our own collector that will simply recompute all values. I'm hesitant as current behavior is obviously intentional. Can anybody help me understand what this behavior is for?
Thank you in advance,
Eugene
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
