CVI2013: _TARGET_PRODUCT_VERSION_ and _TARGET_FILE_VERSION_ troubles

Question

I've just noticed another strange behaviour of CVI 2013, and it's related with precompiled headers (am I the only user of this feature?).
It's very simple to trigger:
 Set up any project for using precompiled headers
Set in Target Settings -> Version Info a version number with auto increment (e.g. 1.0.0.0+) for both file version and product version fields, for the release configuration.
Rebuild the "release" configuration, so to have all files recompiled.
Modify any source that does not trigger precompiled header recompilation
Build the project.
Then the build will terminate with this error messages:
main.c - 2 errors, 2 warnings
1, 1 error: definition of the macro '_TARGET_FILE_VERSION_' conflicts with the definition used to build the precompiled header
1, 1 <built-in>:162:1: note: definition of macro '_TARGET_FILE_VERSION_' in the precompiled header
1, 1 error: definition of the macro '_TARGET_PRODUCT_VERSION_' conflicts with the definition used to build the precompiled header
1, 1 <built-in>:163:1: note: definition of macro '_TARGET_PRODUCT_VERSION_' in the precompiled header
Build failed.
As additional  information please note that there is no reference to _TARGET_PRODUCT_VERSION_  and _TARGET_FILE_VERSION_ macros.
The reason is obvious: the precompiled header retains the old values of these variables.
I don't have found any workaround but to stop using the auto-increment feature.
Carlo A.
Megaris

Answer 1

Luis, I hope that my words didn't sound offensive: it wasn't my intention.
No, I don't do the bulk of my development in release configuration. 
In my applications, I usually have some "release only" and "debug only" code, selected by conditional compilation by using the NDEBUG / _CVI_DEBUG_ predefined constants.
Sometimes, by chance, it happens I had to do a quick fix in the "release only" code. It isn't a frequent event, anyway.
When this happened on CVI 2013, the compilation ended in a fatal error, on perfectly valid code.
The whole scenario is not exactly common, but it could be misleading to other users, too.
I think I can survive   doing only full rebuilds in release configuration: its impact can be made negligible by using a more conventional development pattern.
IMHO all the problems come from the definition itself of the two constants. 
Both of them refer to the version of something that should not exist at compilation time, something that in a logical sequence should come to life only when the executable file is generated, or - more precisely - when resource compiler appends to the executable the version information.
Preprocessor constant must obviously be known in the first phase of compilation, so the compiler is somewhat betting on the build result, hoping that all steps involved in executable generation will be successful.
Given this, these constant should not exist at all.
If someone needs to know at run time the actual executable version number, it's not hard get it by using GetFileVersionInfo() API from version.dll. I don't know if there is some equivalent on Linux.
And if someone claims he/she needs to know at compilation time the version number, then he/she is simply doing it wrong...  
A sort of compromise could be to exclude from the constants any... variable part, e.g. the autoincrementing numbers. After all, a proper costant must be constant, isn't it ?
I'm very interested to hear your opinion.
Carlo A.
Megaris