Currently, some subset of options and platform information is, by default, used to produce a build output directory. The intention of doing this was to make it so that if you built with options set A, building with a different set of options B would not overwrite A, so that if you switched back to option set A you would not need to re-build everything.

Unfortunately, there are several downsides to this approach:

• The generated path may be very long. Sometimes, too long for the toolchain to support.
• There is no guidance on which subset of build options should or should not affect the variant directory. As a result, the behavior is inconsistent.
• There is no way to know, just by looking at the command line, what the build time path to a build artifact will be, which makes it very hard to do exact re-builds of specific targets undef the variant directory.
• Several options which should only really need a re-link end up needing to do a complete re-compile because the output targets are place in different paths.

We also have several features that now render the utility of this scheme questionable:

• We have support for the CacheDir SCons feature, which will store object files from different builds, and replace them when you revert to an older configuration. This obviates much of the gain of deriving the variant directory from options.
• We have the ability to explicitly set the variant directory name with the --variant-dir flag. If a build system user explicitly wants to separate build results between two configurations, or does not wan't to use --cache-dir, they can manually target the build artifacts to different locations.

I propose that completely drop the expansion of variable settings into the variant directory name and rely on the above mechanisms instead.