#1 Is coan 4.2.2 backward compatible with 4.1 ?

[Anonymous]

How to disable the new feature of coan 4.2 : "The source files might themselves contain #define or #undef directives that are active under the given configuration and which may influence its effects."
This should be optional (or at least deactivable).
How to make coan 4.2 behave like coan 4.1 and ignore #define directive in source file and consider only those from command line arguments ?

Thanks you for this great piece of software.

Not related. Proposal : allowing regular expression for -U and -D directive

[Mike Kinghan]

Hi,

I'm open to persuasion about disabling the new evaluation of in-source #defines and #undefs, but I've always regarded the absence of this functionality as a bug. If coan doesn't factor in-source #defines and #undefs into the configuration for the course of a translation unit, this creates scope for coan to fail to resolve #if directives that the preprocessor would resolve and so output conditional code that the preprocessor either would output unconditionally or not output at all.

So what I need to see is: When is it ever desirable for coan *not* to make the same decisions as the preprocessor for a given configuration?

[Anonymous]

You know : one tool, many uses.
You cannot guess how and for what coan will be used.
So one answer to your question is : when the user requests it explicitly because he has very good reason for this.

A more difficult question is : what should be the default behaviour of coan ?
One answer is : the one corresponding to your own usage. The author's privilege ;-)