Currently, we get some EnumString subclass instances out of python configure, and while we could get to use them while running config status as part of configure.py (per bug 1296503), we don't because a) some moz.builds do some checks that fail because of the EnumString checks (legitimately) b) some others fail because they use things like OS_TARGET, which map to a different EnumString subclass depending on the platform, thus failing checks in some cases c) for consistency between running config.status standalone (or it being included from python code) and through configure.py. a) needs fixing. b) variables like OS_TARGET, OS_ARCH and CPU_ARCH probably need to be stringified at the python configure level (definitely the first two, not sure about the latter). c) needs EnumString subclasses's repr to print out an expression that can create the same EnumString subclass instance.
When you say "at the python configure level" where are you thinking? It would be pretty nice if we could persist EnumString all the way into the moz.build context so that testing against invalid values in moz.build would fail.
The three variables I mentioned are special, in that their value alternate between different EnumString subclasses depending on the platform. So propagating them as-is to moz.build is bound to fail. So the easy way out is, for those (and only those) to not propagate them as EnumStrings. And yes, this bug is about propagating the EnumStrings to moz.build (otherwise a) wouldn't need fixing ;) ). On the long run, we need to get rid of OS_TARGET, OS_ARCH and CPU_ARCH in moz.build, and use the equivalent of target.os, target.kernel and target.cpu (and same with host). Maybe we should even propagate the namespaces to moz.build, so that we get something like CONFIG['TARGET'].os, CONFIG['TARGET'].kernel, etc. But that's a discussion for another day.