Q:

Run time determination of compilation options

I need to be able to determine at run time what compilation options were use to build the executable. Is there a way to do this?
EDIT: I'm particularly interested in detecting optimization settings. The reason is that I'm writing commercial software that must run as fast as possible. While I am just modifying and testing the system I don't do all the optimizations because it takes too long. But I am worried that I may accidentally go and release an unoptimized version of the program. What I'd like to do is have the program give me a visual warning at start up saying something like "This is the slow version - do not release".
EDIT: Maybe I could write some little utility to run as a pre-build step? Is the command line stored in some file somewhere? If it is then I could extract it, then write it to some include file as a string and hey presto!
EDIT: My choice is not between debug and release. Debug is way too slow - I reserve that strictly for debugging. My day to day choice is between optimized and super-optimized (including the slow-to-compile link time compilation, or even profile guided optimization).
EDIT: I often make changes to the complex compilation process, different libraries, different pre-defined macros, different source files etc. It seems clumsy to have to maintain multiple, almost-identical project files differing only in a couple of optimization flags. I would much prefer to just, as-and-when-required switch a couple of flags in a single project and re-compile. I just want the executable to self test how it was created.
EDIT: IIRC there is some way to ask the visual studio to create a makefile. Can I ask visual studio to create this makefile for me as a pre-build step?

A:

The best way I know of to pass information from the build system to a running program is via the preprocessor. You can pass preprocessor definitions on the command line, and inside use them to set the value of variables, select code, or whatever with #ifdefs.
So setup your build system to use something like DEBUG_SET for debug its debug builds, etc.

Addressing the second "EDIT", yes the command line for your prebuild and postbuild tools are put in the project's vcproj file. It is an XML file, and you should find it under  at tag Configurations->Tool with a name attribute something like "VCPreBuildEventTool". Try adding one with the GUI and then opening the file in a text editor, and you should see. 
It is fairly common around here to create tools to process vcproj files. I'm wondering if we couldn't use some of those property sheets mentioned in the comments instead though...

A:

I think you might be going about this the wrong way...
See, while Visual Studio starts off giving you just Debug and Release configurations, there's nothing stopping you from adding as many as you like, with whatever compilation settings you like.
Certainly, for day-to-day use, you shouldn't be fiddling with compiler settings and so on. Just set them up once and switch configurations as needed.
To add more configurations, use the Build->Configuration Manager page. There you'll the default Debug and Release, and you can create your own "Super Release" or whatever you want to call it.

A:

Create multiple configurations for your project, for example Debug, Release & Production.  Change the names of the output binaries for each configuration to match across configurations.  For example MyApp_d.exe, MyDll_d.dll for debug, MyApp_r.exe, MyDll_r.dll for Release, and MyApp.exe & MyDll.dll for Production.  This will help to keep all the different flavors straight without having to try to add code (which will be slow and brittle) that will detect at runtime which flavor is running and perform some magic then.

