Home/ Questions/Q 664103
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T23:33:46+00:00

I need to be able to determine at run time what compilation options were

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    To do this right you will need to create an additional configuration called, say “SuperOptimised”. You now have the standard configurations (“Debug” and “Release”) and a third “SuperOptimised”. The problem with this is that it makes the configuration management of the project much harder, to change a common setting between the three configurations, you need to make that change in three places.

    The solution to that is to use “Property Sheets” (“.vsprops” files) and the “Property Manager” tab. You can create a property sheet that is common across all three configurations, and specific sheets for Release, Debug and SuperOptimised. Combine the common settings with the specific settings (using property inheritance) to manage the configurations – the “Property Manager” tab allows you to do this. You can change the “.vsprops” files to change common settings across configurations without changing the configurations themselves.

    More info on Property Sheets here:

    http://msdn.microsoft.com/en-us/library/a4xbdz1e(VS.80).aspx

    Finally if you want to check which configuration was build at runtime, use the preprocessor to define a macro value in the “SuperOptimised” .vsprops file, say “SUPEROPTIMISED”. You can then check whether you have the right build with:

    #ifndef SUPEROPTIMISED
    // Warn the user that this is not a shipping build
#endif

    This may all seem like a lot of work, but managing non-trivial projects (and especially multi-project workspaces) through property sheets greatly reduces the chance of error when making configuration changes.

    • 0